The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35
This patch implements it by emitting .option arch during codegen.
Differential D151730
[RISCV] Support target attribute for function BeMg on May 30 2023, 9:11 AM. Authored by
Details The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen.
Diff Detail
Event Timeline
Comment Actions
Comment Actions Can you separate the change to RISCVAsmPrinter.cpp into it's own review? This looks useful for any case where we have functions in the same model with different function attributes. The attribute((target...) syntax is one way to have that, but there are also others. LTO will see this, and so may other frontends. This will also help with review as the set of people who can review RISCV backend changes and clang frontend changes is fairly non-overlapping.
Comment Actions FYI, this change appears to be a partial diff. Locally, I need to add RISCV to supportsMultiVersioning() to get this to work at all. Comment Actions Isn't multiversioning a separate thing that builds on top of per-function target attributes? Comment Actions That's what I thought. The supportsMultiVersioning call was in an earlier version of the patch that I asked about. Comment Actions Yeah, looks like I got confused. I hadn't expected that target("default") would automatically be considered multi-versioning, even when there was one definition of the function. As such, my test case was accidentally testing multi-versioning even when I hadn't meant to. Comment Actions
Comment Actions Remove some condition because RFC doesn't support it. (Must include prefix arch|cpu|tune)
Comment Actions Update to lastest spec
Comment Actions
Comment Actions
Comment Actions In local testing, I'm seeing some very odd behavior with target attributes. It looks like target attributes are being properly handled if clang -cc1 is directly invoked, but not if the clang driver is used. Or at least that's currently my best theory. This works: This does not: Comment Actions I think I figured out what is going on here. The clang driver materializes all of the target-features at the cc1 invocation command line (including the negative ones). If I manually duplicate this at the cc1 command line, that one stops working. |
Can we use something like