@boomanaiden154@hachyderm.io

Aiden Grossman @boomanaiden154@hachyderm.io

· 5mo ago

With the following patch stack (that definitely needs some cleanup):
1. https://github.com/llvm/llvm-project/pull/191664
2. https://github.com/llvm/llvm-project/pull/191579
3. https://github.com/llvm/llvm-project/pull/191665
4. https://github.com/llvm/llvm-project/pull/191667
5. https://github.com/llvm/llvm-project/pull/192371
6. https://github.com/llvm/llvm-project/pull/192830
7. https://github.com/llvm/llvm-project/pull/192831

We can now bootstrap LLVM using the NewPM on x86! All LLVM tests pass except for Other/print-on-crash.ll which needs some further investigation.

github.com

5

0

1

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 5mo ago

Half Dome on 4/16/25. It was long (~20 miles car to car with trail detours) and I am not very comfortable walking up slippery 45+ degree granite slabs even when harnessed in, but it was a pretty amazing hike.

2

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 7mo ago

Replying to

@shafik@hachyderm.io @chandlerc@hachyderm.io @meowray@hachyderm.io Yep. The incentive structures here are not naturally aligned to building a healthy open source community. Doing reviews for patches that might not provide immediate (or any) benefit is time spent that is harder to justify than time spent working on immediately useful features. But it is immensely important to the health of the community which is the reason any of this can happen in the first place. Some places seem to realize this and others do not. I hope more come around as time goes on.

3

6

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 5mo ago

Replying to

@regehr@mastodon.social Good to here that some can be addressed. I figured some could but am not familiar enough with the implementation to have any idea what is and what is not. Agreed that differential fuzzing within the common subset is still useful. Sounds good about punting (slightly) to the future. There's some llubi patches that probably still need to land, like floating point support. All good on the compiler explorer move. It will happen eventually. 🙂

1

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 5mo ago

Replying to

@regehr@mastodon.social I've wanted to do differential fuzzing when llubi is more complete, but based on the README, alive-exec has a lot of limitations that will make testing reasonable programs somewhat difficult, on top of likely not catching a lot of issues:

For example, the function cannot take inputs, cannot use memory, cannot depend on undefined behaviors, and cannot include loops that execute too many iterations.

1

2

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 7mo ago

Replying to

@malwareminigun@infosec.exchange @AaronBallman@social.vivaldi.net @meowray@hachyderm.io @chandlerc@hachyderm.io LLVM has okay premerge CI (ensures that the unit/regression tests pass on x86-64/AArch64 Linux and x86-64 Windows). Alive is not run precommit at all (although some subareas like InstCombine generally require Alive2 proofs in patch descriptions). Precommit CI also isn't going to solve problems like ensuring the design work of a patch is reasonable. LLM wielding users offloading that onto maintainers I think is going to create problems no matter how good of precommit CI exists. As a side note, despite all the fuzzing/formal verification/testing that LLVM goes through, I still end up debugging a couple miscompiles/timeouts/crashes a week and across my team we probably deal with ~5x that number.

2

4

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 7mo ago

Replying to

@malwareminigun@infosec.exchange Definitely not doing that. Sorry if I made it seem otherwise. Just trying to add some additional context/perspective. We're definitely in a lucky spot to have researchers interested in helping us solve these problems. 🙂

1

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 7mo ago

Replying to

@chandlerc@hachyderm.io @meowray@hachyderm.io @shafik@hachyderm.io I think our leaders do a good job of this. Most of our lead maintainers review much more code than they commit themselves. I've also found them to be reasonably encouraging towards new reviewers and care deeply about the experience for existing reviewers. I for one have started trying to do more reviews because of a call from a lead maintainer. I'm not sure one can say that they have been effective at shifting an entire project's culture towards doing an effective number of reviews given that is not happening. But they certainly seem to be putting quite a bit of effort into trying.

1

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 7mo ago

Replying to

@AaronBallman@social.vivaldi.net @meowray@hachyderm.io @chandlerc@hachyderm.io It's sad to hear that AI usage is having such an impact on reviewers. Ideally the AI policy lets reviewers push back on that and label contributions as extractive, but I think there are many AI contributions where they take much more time to review while not technically being "extractive". Echoing other reviewer's sentiments, my experience reviewing PRs produced with AI assistance has been frustrating. There are usually many more rounds of review and you can't trust that the contributor actually thought about all of the changes that they made. I still think AI can be useful in some limited contexts. But only people with a deep knowledge of the code base are going to be effective at using it for individual PRs, which are generally not the people actually using it. I don't know if there's a good solution to this yet. I think tools like vouch are interesting, but that feels like too big of a compromise on fostering a welcoming community for LLVM specifically.

1

7

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 8mo ago

Replying to

@nikic@mastodon.social For what it's worth, I do have a E2E prototype of using the NPM for codegen. My asmprinter port is a bit of a hack though and needs some rethinking before it will land upstream.

1

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 1mo ago

@llvm@fosstodon.org Going to a conference for the compiler that shall not be named? Blasphemy!

On a more serious note, I think this is a really good thing. I think there's a lot we can learn from each other that is currently mostly siloed.

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 5mo ago

@artagnon@mathstodon.xyz Yeah, they can be landed independently. I just have them stacked given it made it easier to keep everything on the same branch locally so I could do a bootstrapping build.

0

Aiden Grossman @boomanaiden154@hachyderm.io

· 7mo ago

Replying to

@chandlerc@hachyderm.io @meowray@hachyderm.io Also, to your last point about LLVM struggling a bit with effective infrastructure use, it sounds like you have some specific ideas in mind that would be high value?

0

2

0