[llvm-dev] Per-function subtargets

[Eric Christopher via llvm-dev]

Hi Scott,

That one is a little different. You'd like to be able to instantiate a
TargetMachine with a default - if nothing else it'd be hard to change
that particular API usage though it would be nice. That said, they're
just defaults for an initial subtarget. Anything on a function will
override them if you need to, but this keeps a bit more compatibility
with existing IR and use.

-eric

On Wed, Mar 13, 2019 at 8:09 PM <scott at scottlinder.com> wrote:
>
> 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