Smeenai,
I agree vibecoded has a negative connotation but to be clear, I did not write this code so I find the term is accurate. In general I instructed it to copy large portions of code from other targets. I initially instructed it to copy the Lanai target because it’s the simplest target. I immediately ran into problems because of issues with limited registers in EZH and issues with having insufficient PC relative load range for constants.
Most of my time as a developer has been on ARM cores and I recognized that EZH is very similar to Thumb 1. They both have a similar PC relative load range, no hardware divide, no float, and the same number of readily accessible registers (R0-R7 (most thumb 1 instructions cannot access the higher registers)). Because of this, I asked it to copy the ARM constant island, soft float, frame pointer handing, base pointer handling and for the most part the ABI.
A lot of this just worked (verified by homegrown and GCC torture tests) however major issues were encountered around a few key areas:
- 16 bit support. EZH can only perform 8 and 32 bit loads and stores. I instructed it to insert 2, 8 bit loads/stores to emulate 16 bit support.
- Signed comparison support. EZH doesn’t have an overflow flag but does have a carry flag. I had it inject a bit toggle instruction to toggle the 31st bit (simulating an XOR) on both inputs before comparison to allow for an unsigned comparison using the carry flag.
- Signed 64 bit support. Figuring out how to get lowering to work correctly with the signed comparison issue was tricky.
- Interrupt support. EZH doesn’t support interrupts so I had it make another pass to inject conditional gotos using bitslice condition flag to jump to an “interrupt” handler in front of every goto instruction.
- The constant island. The ARM constant island worked fine however it continued to mess it up with the changes above and I had to carefully guide it through. It would often believe it hit some silicon pipeline bug when loads were near gotos. It couldn’t be self guided here because EZH has the concept of a “scheduled branch” in the EZH application note which really means if desired, EZH can execute 2 instructions after a goto instruction and then actually jump to the new location. AI latched onto this concept and was confident that EZH would always do this. Since AI can develop in a build and test loop, if left alone it would just generate insane code.
This is where I spent most of my time working directly on the code with AI. I also spent a lot of time telling to clean up, de spaghetti code or remove changes it made to non EZH code.
While I have read every line that it has output, I admit, do not understand how every line works. I have contemplated on whether this is an issue or not and I keep coming back to this is not very different from code I wrote a long time ago and forgot how it works. I am capable of learning or relearning code to fix it especially since I generally understand how it works. I’m also left with the thought, should I know how it works if it works fine? I’m honestly not sure and I think it depends on the situation. If it has security, human safety implications or may cause the system to crash, it is not fine, otherwise it probably is.
jh7370, you are right, there are many trivial and pretty much boiler plate changes. It’s worth pointing out that 40 of the files being touched are nothing but adding EZH to a list of targets.
Anyway, the part that I’m still most confused about is what is the point of experimental targets? I see experimental as meaning it’s not ready for main for whatever reason. It seems that LLVM views it as exclusively a staging area ( LLVM Developer Policy — LLVM 23.0.0git documentation “new targets are always added as experimental until they can be proven stable, and later moved to non-experimental”) before entry into main and I don’t think this makes a lot of sense. In my opinion the real gate from transitioning from experimental to main should be how many users there are and nothing else.
For example if the x86 target was incredibly low quality, AI generated and poorly tested, it doesn’t matter, it still must be in main because everyone expects it to be there because everyone uses it. This helps lean into your point MaskRay “don’t impose a cost on 99.999% users that don’t build code with LLVM” [insert seldom used target name here]. I suspect this is a good rule: if there are more than 100 users, it likely should be in main. If less, it should fall back out to experimental.
With that reasoning Lanai should not be a main line target. Looking at git history, it doesn’t appear that Lanai has had any real changes in a very long time. Maybe others should not be as well.
I think experimental should mean experimental. Experimental targets should not go through as rigorous of a review process (it’s an experiment) nor should they be guaranteed to build or work ( LLVM Developer Policy — LLVM 23.0.0git documentation “Test failures, bugs, and build breakages that only appear when the experimental target is enabled, caused by changes unrelated to the target, are the responsibility of the community behind the target to fix”). In the event that a target should be upgraded to a main target, it should then go through the main review process.
I think experimental targets get too much effort/attention with the current LLVM ideology. In my opinion the LLVM team would benefit by having a real experimental target section. This allows people to soft bring their target into LLVM, have the exposure of being in LLVM, not suffer from having to rebase their forks constantly and spreads the burden of these experimental targets to people who actually use it (I’m suggesting people are often scared off by someone’s non official fork, leading to these forks getting limited to no attention). LLVM benefits because it becomes the place where support for all CPU architectures (new, old, heavily used, disused) is found, driving more interest in the project. If someone needs an experimental target and it’s broken, it’s their problem to fix it. This is likely substantially easier than bringing up a whole target from scratch. Maybe this should be a special folder in llvm-project so it doesn’t pollute the non experimental targets? I hear your point MaskRay about having AI rebase and you are totally right it but this doesn’t help with exposure.
Wrapping all of this up, I think EZH is roughly equivalent to Lanai. It’s an architecture which is both obscure and posses a very limited community and there are millions of them already deployed. I’m still a bit confused that Lanai is main and EZH is out of tree but I’m ok with it.
I agree with the general consensus here. With the way LLVM is today it seems like it would be best for EZH to live as an out of tree fork. I think this is primarily based around an unclear need for the EZH target at this point and also very limited community. I’m not sure if we found consensus about whether being AI assisted is an issue or not.
Thanks for all of your thoughts here,
Richard