[Mlir-commits] [clang] [llvm] [mlir] [IR] Explicitly specify target feature for module asm (PR #204548)

[Nikita Popov]

nikic wrote:

> I'd like to consider future extensions a little more before we go forward with this.
> 
> Discussion #67698 suggests we might want to construct a "symbol table" for inline asm, and store it in the IR. (I guess this actually fixes #67698 in a different way, though?)

Right, there is even a PR for this at https://github.com/llvm/llvm-project/pull/174995. Ultimately, I'm not convinced this is the right direction, as indicated by some of the last comments on the discussion there. It's not really a full solution to the problem, and I'm not sure it's a worthwhile change if it's not necessary to solve the LTO problem.
 
> #112920 might require attaching options related to include paths to the inline asm.
> 
> For [LTO with linker scripts](https://discourse.llvm.org/t/rfc-lto-lld-lto-with-linker-scripts-implemented/91089), we might want to attach origin filename, so we can emit that into the emitted object file.
> 
> We don't need to implement all of that immediately, of course, but maybe it makes sense to allow more generalized "metadata" so we don't need to hack core IR datastructures every time we want to extend the list of properties?

Yes, I do expect that we'll add more module assembly properties now that the mechanism exists.

Are you suggesting we shouldn't try to hardcode the list of supported properties in the first place, and just make this an arbitrary string to string mapping?

https://github.com/llvm/llvm-project/pull/204548