Put essential functionality into LLVM instead of clang

[shawnl]

Is it at all possible to put the core functionality (RecordFieldReorganizer.cpp and RecordLayoutBuilder.cpp) into LLVM, instead of clang? This would require putting the C ABI[1] also in LLVM (which is a good thing, as most LLVM front-ends want C ABI compatibility).

I understand that might slow down this project (especially as you are geting close to merging this), but there is a long history of putting generally useful functionality in clang instead of LLVM for expediency, and it leaves other LLVM front-ends in the dark.

I think this has extra importance for this project, in that putting this in clang prevents interoperability with other languages.

[1] for structs. Var arg handling is much more difficult, and not necessary to get this into LLVM. ABI handling can still fall back to clang.

[shawnl]

OK, from reading only the ARM64 passing conventions, it might be able to get away with this without touching the C ABI.

[connorkuehl]

@shawnl Thanks for the suggestion! I can't speak for the rest of the team on this but it's certainly an interesting idea. I think it's worth discussing especially since this project requires a fair bit more work anyway before it gets merged.

That said, I can't make this project a priority at the moment, so I don't think it's fair for me to approve / deny anything at this point.

Sorry that this reply is rather useless. I just didn't want you to think you were being ignored.

[shawnl]

My point is that most languages these days that intend to be compiled to machine code want compatibility with the C ABI, and randstruct will be part of that (and can be made compatible between languages by sharing the seed). LLVM knows what a struct is.

[shawnl]

So there was some valid pushback on this in the Phrabricator issue. So all I really ask is that the implementors of this consider other frontends, and the possibility of sharing randomized structs between differn't front-ends. (passing the key to each front-end)

Maybe it is possible to design rand-struct in such a way that the most important code does not depend on clang or llvm internals. (only the llvm C++ api).

[shawnl]

Depends on #47