I've been trying to understand the current state of subtargets and subtarget features in LLVM. It seems like the presence of "target-cpu" and "target-features" attributes on IR functions are currently intended to take precedence over the module-level (TargetMachine) versions. See X86TargetMachine::getSubtargetImpl for an example of this. However, this feels like it is half-way between two solutions (either all-module-wide, or all-function-specific), and some previous discussions like https://groups.google.com/forum/#!topic/llvm-dev/2hp9aARHEJA ([LLVMdev] Embedding cpu and feature strings into IR and enabling switching subtarget on a per function basis) seem to reinforce that feeling. Is the intent still to eventually remove the module-level subtarget options entirely? Or will the two continue to coexist? Is it up to the target to decide how to "merge" the two, or is the "all or nothing" approach the right one? -- Scott
The intent is that there should be no module level attribute that affects anything beyond ABI level decisions. The module level attributes should control things where you cannot link two modules together and still have an ABI conforming program. Everything else should be on the function and such the subtarget. Make sense? -eric On Wed, Mar 13, 2019 at 1:51 PM via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > I've been trying to understand the current state of subtargets and > subtarget features in LLVM. It seems like the presence of "target-cpu" > and "target-features" attributes on IR functions are currently intended > to take precedence over the module-level (TargetMachine) versions. See > X86TargetMachine::getSubtargetImpl for an example of this. However, this > feels like it is half-way between two solutions (either all-module-wide, > or all-function-specific), and some previous discussions like > https://groups.google.com/forum/#!topic/llvm-dev/2hp9aARHEJA ([LLVMdev] > Embedding cpu and feature strings into IR and enabling switching > subtarget on a per function basis) seem to reinforce that feeling. > > Is the intent still to eventually remove the module-level subtarget > options entirely? Or will the two continue to coexist? Is it up to the > target to decide how to "merge" the two, or is the "all or nothing" > approach the right one? > > -- > Scott > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
That makes sense, but when you say "module level attribute" you mean in the IR, correct? I am asking more about the CPU and feature strings in the TargetMachine. There are are effectively (but maybe not formally) "global subtarget features" on the TargetMachine which functions lacking a "target-features" attribute inherit. This also doesn't seem to interact well with how Clang elides the attribute entirely for an empty feature string, because each target I've looked at treats the "absent" case differently than the "present but empty" case. Is removing the CPU and feature strings from the TargetMachine a goal? Scott On 2019-03-13 20:27, Eric Christopher wrote:> The intent is that there should be no module level attribute that > affects anything beyond ABI level decisions. The module level > attributes should control things where you cannot link two modules > together and still have an ABI conforming program. Everything else > should be on the function and such the subtarget. > > Make sense? > > -eric > > On Wed, Mar 13, 2019 at 1:51 PM via llvm-dev <llvm-dev at lists.llvm.org> > wrote: >> >> I've been trying to understand the current state of subtargets and >> subtarget features in LLVM. It seems like the presence of "target-cpu" >> and "target-features" attributes on IR functions are currently >> intended >> to take precedence over the module-level (TargetMachine) versions. See >> X86TargetMachine::getSubtargetImpl for an example of this. However, >> this >> feels like it is half-way between two solutions (either >> all-module-wide, >> or all-function-specific), and some previous discussions like >> https://groups.google.com/forum/#!topic/llvm-dev/2hp9aARHEJA >> ([LLVMdev] >> Embedding cpu and feature strings into IR and enabling switching >> subtarget on a per function basis) seem to reinforce that feeling. >> >> Is the intent still to eventually remove the module-level subtarget >> options entirely? Or will the two continue to coexist? Is it up to the >> target to decide how to "merge" the two, or is the "all or nothing" >> approach the right one? >> >> -- >> Scott >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev