[llvm-dev] Per-function subtargets

[via 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