llvm dev - Mar 2019 - Per-function subtargets

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