ilovepi wrote: > @mysterymath, @ilovepi, @efriedma-quic, thank you for review! > > > Generally, I'd like to minimize the amount of code for LTO that's in > > clang/: we have other frontends that do LTO, and we don't want them to > > copy-paste/translate a bunch of new code just to make inline asm work the > > way it's supposed to. Can we refactor this? > > Sure! Perhaps we can move `ModuleSymbolTable::CollectAsm*` calls and metadata > construction to `ModuleSymbolTable` itself? Then Clang or other frontends can > call `ModuleSymbolTable` to get a constructed metadata, and set it as a flag. > Or let `ModuleSymbolTable` to update a Module. >
There's a lot of options on where this logic could live. There's an argument that it'd be appropriate to maybe even move it into the module initialization, but there's other places that would be just as good IMO, including the symbol table. @nikic do you have any thoughts on where the best place for code like this would be? > > Can you add a RISC-V test? We've had lots of problem w/ target features in > > LTO w/ RV, and the module level inline asm in particular. To date we've > > done a few things to try and mitigate that by plumbing them through the > > backend. I'd like to know how this patch ends up interacting w/ that, and > > whether this solve some of the remaining issues, or if we need further > > triage for that backend. > > #50591, #65090, #69780 are all related to some extent. > > Yes, I'm going to add a test from #67698 for RISC-V, and check other issues > that you mentioned. Not all of them are minimal, so I may need some help > there. To start, that one is probably fine. https://github.com/llvm/llvm-project/pull/174995 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
