A Tech Nerd with a finance mind.
Heuristics: candidate set for getting the phi instruction out to match the set between target dialect and source dialect.
Soundiness: CBMC Z3 for determining the correctness statically.
To extract φ (phi) with the candidate set, the algorithm follows a bottom-up synthesis approach. Here is a summary of the process:
The above is from one dialect to the other
The evaluation over PollyBench on 8700k and 3990x summary tells us about the performance and effectiveness of the mlirSynth algorithm in raising programs to higher-level dialects within MLIR. The TPU performs well over LLVM for all(because LLVM is not a good IR for heterogenous accelerator) It provides information on the synthesis time, validity checks, and the impact of type information and candidate pruning on the synthesis process. The summary also mentions the performance improvement achieved by the raised programs compared to existing compilation flows, as well as the potential for further improvements and future work.
我同事这人过去六个月的进步不如上一周的进步。因为yyw在旁边点醒了他。
首先static instrument把启动位置和offset弄了，把instrument code的basic block都加个offset。把jmp map metadata放最后，第一个问题是在6.2.0-36 kernel和5.4.0行为不一样，rtdl.c:1306会segfault原因是p_header在两个kernel里的physical和virtual address的mapping行为不一样。
其次spec17 gcc有selfmodifying code我们不支持。
其次perl在destructor会炸，因为对dtor的libc处理很傻逼，也是一个selfmodifying code实现。
推荐阅读
众所周知，yyw眼中第一重要的是事业，第二重要的是老婆，第三重要的才是无尽的小裙子。但突然发现后两个好像并没有区别，把头发剃了和以前没啥区别，也可以戴假发穿小裙子，我也不是非常在意身体，以为我觉得对身体损伤最小的变性方式并没有出现，所以不会让自己过于陷于不受控制的境地。
Steve Jobs能在胰腺癌移植手术后继续苟活6年，yyw也能盼望这个世界能早日医疗进步，今天的每一天和昨天都不一样，尤其是在这个能最大限度释放yyw所想的加州。
所以我认为任何意义上的性别都不重要，重要的是唯心和以一种舒服的方式生活下去，如果我的皮肤能保持光滑的女性特质，这就足够装下yyw的灵魂了。我认为没有解决一个问题，纯粹是因为你没有站在更高的位面观测这个世界，并不是这个世界不存在，我尝试用激烈的测试手段来观测这个世界来让我达到一个更高的位面，但是同时又希望身边的人能获益。
所以老婆要yyw怎么样，都可以，只要她不离开yyw且同意给yyw生小孩。
The current GPU slicing by MIG is way to higher granularity.
The state of the art needs GPU on getting the service mesh requests letting you serve it, normally the launch time of the kernel and the data movement takes the most of the execution. Pre execution by MLIR JIT statically optimize out the launch but do GPU context coroutine.
We first use the Arithmetic Isomorphism for a single thread using split/tile reorder and unroll. 
Then we have the Memory Isomorphism for intel VNNI, basically mark the loop invariant and lower to the other precision and other sized tensorized operations. 
Finally we do the transformation for Loop Recorganization for registers 
I've been mentoring the SCC for two years now; I think for this year, Flang+MLIR is the newest and greatest technology to accelerator.
Address Translation and coherency have been explored before, during CCIX or PIM, but the challenge is address translation at that time was not a ratified feature for the fabric, and putting both place page tables with TLB accelerated is not a scaling thing.
The current trend of developing AI accelerators is not following Von Neumann's view. What was Von Neumann's outcome? Multi-tenancy, virtualization, fine-grained scheduling, mapping back to the compiler, and cross-platform live migration. Why is this property deprecated in a lot of so-called Von Neumann Architecture? It's because the current microarchitecture state is too complicated to fully manifest for the programmers to understand, which cancels out a lot of people's interests. I think Professor Jiang Yanyan's abstraction of the operating system as an automaton is incorrect because of the explosion of the transparent state to OS; the GPU is not fully debuggable, letting along other coarse-grained architecture in TPU. So if you couldn't fine-tune your scheduling, the outcome is if the workload is constantly changing, your chip and infrastructure will never beat Nvidia because they have better infrastructure, and TFLOPS is close to the extreme of what any chip can do. Tomorrow, if I want to deploy LLM+HPC, all the DSA will just die because of this. I think the abstraction of CUDA or the abstraction of C++ language level is good for programmers to program, but far more deviated from the Von Neumann property all done. If other academic proposals want to commercialize either one of the DSAs, like TPU, CGRA, Like-brain, or PIM, they might lose any of the above Von Neumann properties and won't be useful if those architectures don't have the 10x speedup and agility that CUDA and GPU provide.
In terms of virtualization, GPUs are never ready for virtualization because the current virtualization techniques on GPUs are still VFIO, which is CPU-dominated and slow. Ray, as I mentioned before, has a Von Neumann Memory Wall, and epoch-based is not fine-grain granularity. and we should never adapt to the front end like PyTorch or CUDA because it doesn't change anything in the meaningless abstraction or working for monopoly; we need a revolution from the architecture and back to the abstract to the language. We need to go back to normal; why did we lose this property? In the realm of modern GPU architectures, there's an emerging sentiment: as long as we utilize CUDA's Just-In-Time (JIT) compilation capabilities, we can achieve a faster Virtual Instruction Set Architecture (ISA)—for instance, something akin to WebGPU/Vulkan/ptx. This could lead to virtualization speeds surpassing traditional methods like VFIO with no semantic or performance sacrifice.
Am I saying DSA is no longer useful? No, if everything in a space is very mature, I guess the DSA will eventually win, but things change every day. Speculative decoding is mathematically the same as whole decoding, saving your training set 10 times, so your TPU is not agile enough to tailor to this change, but your GPU can quickly adopt the new math advancement. TPU has an inference market. If Google Gemini is going to take everybody in the next month, the TPU behind it will be very money-saving in terms of the electricity cost, which only Google can do in the entire universe. Other technologies, like CGRA or like-brain technology, are unsolvable in the near future.
ExaScale aims to beat Nvidia, not by breaking the monopoly that Nvidia has, but first by making transparent migration over different GPUs and connecting them within a memory pool that is not Nvidia's alone. This will facilitate price competition because Nvidia will no longer have competitive edges. The second is to hack the interconnect through CXL or another faster fabric that beats NVLink with software hardware codesign like CXLMemUring. I guess this movement will be the future of how we integrate everything!
I think TPU is wrong, RVV is wrong, Google WSC price calculation is deprecated, and X86 is not as bad as RISCV, so I guess we need to revisit Computer Architecture: A Quantitative Approach. The main fallacy is that most of the work added is David's own work, neither guiding anything in the arch space nor having a profound impact that endures the testimony of time. I think Arch should have codesign, but not VLIW, and should not redo the things that have been discussed a long time ago. The ideology of the whole book misled the architect into having new ideas to thrive in this golden age. I'm saying this because I found Thead's fallacy in RVV and many other fallacies, and programmers' view of this is based on those misleading books.
Implemented in GO and codegen to MLIR with a standard library implemented in C++. I would say it is currently just a frontend of Python that codegen to MLIR with cohesion to Python FFI and CFFI, like what I did for ChocoPy-LLVM [6]. I think Chris' idea is to map the Python semantics, especially the memory model, to Rust or C++ so that every memory can be managed as RAII with shared ptr plus some workarounds without GC. Suddenly, I feel that the transition from LLVM to MLIR is a very natural thing. Instead of defining a set for AMX, AVX512, and NVVM separately, it's better to integrate them.
Static Analysis
Implementation of LLDB and MLIR
Debug with Location info
MLIR lowering to GPU/CPU heterogeneous code
var y : __mlir_type.i1
if x:
y = __mlir_op.`index.bool.constant`[value : __mlir_attr.`true`]()
else:
y = __mlir_op.`index.bool.constant`[value : __mlir_attr.`false`]()
Currently, there's no MLIR code generated, and I don't want to do RE to dump that. You can write some MLIR implementation in amdgpu to force heterogeneous code.