[llvm-dev] Subtarget Initialization in <ARCH>TargetMachine constructor

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] Subtarget Initialization in <ARCH>TargetMachine constructor

Matthias Braun via llvm-dev
Hi,

I found some different discrepancy on how Subtarget is created
between some arch specific TargetMachine constructor.
For example, for BPF/Lanai:

BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT,
                                   StringRef CPU, StringRef FS,
                                   const TargetOptions &Options,
                                   Optional<Reloc::Model> RM,
                                   Optional<CodeModel::Model> CM,
                                   CodeGenOpt::Level OL, bool JIT)
    : LLVMTargetMachine(T, computeDataLayout(TT), TT, CPU, FS, Options,
                        getEffectiveRelocModel(RM), getEffectiveCodeModel(CM),
                        OL),
      TLOF(make_unique<TargetLoweringObjectFileELF>()),
      Subtarget(TT, CPU, FS, *this) {
  initAsmInfo();
}
LanaiTargetMachine::LanaiTargetMachine(const Target &T, const Triple &TT,
                                       StringRef Cpu, StringRef FeatureString,
                                       const TargetOptions &Options,
                                       Optional<Reloc::Model> RM,
                                       Optional<CodeModel::Model> CodeModel,
                                       CodeGenOpt::Level OptLevel, bool JIT)
    : LLVMTargetMachine(T, computeDataLayout(), TT, Cpu, FeatureString, Options,
                        getEffectiveRelocModel(RM),
                        getEffectiveCodeModel(CodeModel), OptLevel),
      Subtarget(TT, Cpu, FeatureString, *this, Options, getCodeModel(),
                OptLevel),
      TLOF(new LanaiTargetObjectFile()) {
  initAsmInfo();
}

Note that Subtarget is created as part of constructor. On the other hard, initAsmInfo() tries to create a subtargetinfo as well. The "Subtarget" created here later on is returned through:
  const LanaiSubtarget *
  getSubtargetImpl(const llvm::Function & /*Fn*/) const override {
    return &Subtarget;
  }

ARM/X86 does differently.
ARMBaseTargetMachine::ARMBaseTargetMachine(const Target &T, const Triple &TT,
                                           StringRef CPU, StringRef FS,
                                           const TargetOptions &Options,
                                           Optional<Reloc::Model> RM,
                                           Optional<CodeModel::Model> CM,
                                           CodeGenOpt::Level OL, bool isLittle)
    : LLVMTargetMachine(T, computeDataLayout(TT, CPU, Options, isLittle), TT,
                        CPU, FS, Options, getEffectiveRelocModel(TT, RM),
                        getEffectiveCodeModel(CM), OL),
      TargetABI(computeTargetABI(TT, CPU, Options)),
      TLOF(createTLOF(getTargetTriple())), isLittle(isLittle) {
...
}
It does not create a separate Subtarget, and its getSubtargetImpl() tries to get the value
from SubtargetMap.

Is there any downside to keep BPFTargetMachine as is? Or it is worthwhile to implement it in a similar way to X86/ARM?

Thanks!

Yonghong


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Subtarget Initialization in <ARCH>TargetMachine constructor

Matthias Braun via llvm-dev
On 22 August 2017 at 23:39, Y Song via llvm-dev <[hidden email]> wrote:
> Hi,

Hi Yonghong.

> I found some different discrepancy on how Subtarget is created
> between some arch specific TargetMachine constructor.
> For example, for BPF/Lanai:
>
> <snip>
>
> Note that Subtarget is created as part of constructor. On the other hard,
> initAsmInfo() tries to create a subtargetinfo as well. The "Subtarget"
> created here later on is returned through:
>   const LanaiSubtarget *
>   getSubtargetImpl(const llvm::Function & /*Fn*/) const override {
>     return &Subtarget;
>   }

Ok, so BPF and Lanai initialize a BPFSubtarget and LanaiSubtarget in
the initializer list for BPFTargetMachine and LanaiTargetMachine. I'm
not sure I quite follow your concern about initAsmInfo, as that
accesses an MCSubtargetInfo rather than a subclass of Subtarget.


> ARM/X86 does differently.
> ARMBaseTargetMachine::ARMBaseTargetMachine(const Target &T, const Triple
> &TT,
>                                            StringRef CPU, StringRef FS,
>                                            const TargetOptions &Options,
>                                            Optional<Reloc::Model> RM,
>                                            Optional<CodeModel::Model> CM,
>                                            CodeGenOpt::Level OL, bool
> isLittle)
>     : LLVMTargetMachine(T, computeDataLayout(TT, CPU, Options, isLittle),
> TT,
>                         CPU, FS, Options, getEffectiveRelocModel(TT, RM),
>                         getEffectiveCodeModel(CM), OL),
>       TargetABI(computeTargetABI(TT, CPU, Options)),
>       TLOF(createTLOF(getTargetTriple())), isLittle(isLittle) {
> ...
> }
> It does not create a separate Subtarget, and its getSubtargetImpl() tries to
> get the value
> from SubtargetMap.
>
> Is there any downside to keep BPFTargetMachine as is? Or it is worthwhile to
> implement it in a similar way to X86/ARM?

My understanding is that SubtargetMap is used to allow different
subtargets to be returned for different functions/modules based on
attributes (e.g. one function might be soft-float, another function
might have a particular feature string or CPU in its attributes. I've
CCed in Eric Christopher who worked on this and can hopefully clarify
or correct me. From what I remember of BPF, I don't think it has
different subtargets and so wouldn't really benefit from moving
towards using a SubtargetMap unless it gained new subtargets.

Hope that helps,

Alex
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Subtarget Initialization in <ARCH>TargetMachine constructor

Matthias Braun via llvm-dev
Thanks, Alex. See my comments below.

On Wed, Aug 23, 2017 at 12:59 AM, Alex Bradbury <[hidden email]> wrote:

> On 22 August 2017 at 23:39, Y Song via llvm-dev <[hidden email]> wrote:
>> Hi,
>
> Hi Yonghong.
>
>> I found some different discrepancy on how Subtarget is created
>> between some arch specific TargetMachine constructor.
>> For example, for BPF/Lanai:
>>
>> <snip>
>>
>> Note that Subtarget is created as part of constructor. On the other hard,
>> initAsmInfo() tries to create a subtargetinfo as well. The "Subtarget"
>> created here later on is returned through:
>>   const LanaiSubtarget *
>>   getSubtargetImpl(const llvm::Function & /*Fn*/) const override {
>>     return &Subtarget;
>>   }
>
> Ok, so BPF and Lanai initialize a BPFSubtarget and LanaiSubtarget in
> the initializer list for BPFTargetMachine and LanaiTargetMachine. I'm
> not sure I quite follow your concern about initAsmInfo, as that
> accesses an MCSubtargetInfo rather than a subclass of Subtarget.

The following is what I observed:
Both Subtarget constructor and initAsmInfo will eventually create
a MCSubtargetInfo, which calls InitMCProcessorInfo.

void MCSubtargetInfo::InitMCProcessorInfo(StringRef CPU, StringRef FS) {
  FeatureBits = getFeatures(CPU, FS, ProcDesc, ProcFeatures);
  if (!CPU.empty())
    CPUSchedModel = &getSchedModelForCPU(CPU);
  else
    CPUSchedModel = &MCSchedModel::GetDefaultSchedModel();
}

If you have -mcpu=help in your command line
llc -march=<> -mcpu=help ...

The help information will be printed out twice because getFeatures will printout
the help info if both ProcDesc and ProcFeatures are not empty.
This is not really elegent. What I am wondering is whether there are other
side effect of this approach or not. If not, maybe I can live with this
for a while....

>
>
>> ARM/X86 does differently.
>> ARMBaseTargetMachine::ARMBaseTargetMachine(const Target &T, const Triple
>> &TT,
>>                                            StringRef CPU, StringRef FS,
>>                                            const TargetOptions &Options,
>>                                            Optional<Reloc::Model> RM,
>>                                            Optional<CodeModel::Model> CM,
>>                                            CodeGenOpt::Level OL, bool
>> isLittle)
>>     : LLVMTargetMachine(T, computeDataLayout(TT, CPU, Options, isLittle),
>> TT,
>>                         CPU, FS, Options, getEffectiveRelocModel(TT, RM),
>>                         getEffectiveCodeModel(CM), OL),
>>       TargetABI(computeTargetABI(TT, CPU, Options)),
>>       TLOF(createTLOF(getTargetTriple())), isLittle(isLittle) {
>> ...
>> }
>> It does not create a separate Subtarget, and its getSubtargetImpl() tries to
>> get the value
>> from SubtargetMap.
>>
>> Is there any downside to keep BPFTargetMachine as is? Or it is worthwhile to
>> implement it in a similar way to X86/ARM?
>
> My understanding is that SubtargetMap is used to allow different
> subtargets to be returned for different functions/modules based on
> attributes (e.g. one function might be soft-float, another function
> might have a particular feature string or CPU in its attributes. I've
> CCed in Eric Christopher who worked on this and can hopefully clarify
> or correct me. From what I remember of BPF, I don't think it has
> different subtargets and so wouldn't really benefit from moving
> towards using a SubtargetMap unless it gained new subtargets.
>
> Hope that helps,
>
> Alex
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Subtarget Initialization in <ARCH>TargetMachine constructor

Matthias Braun via llvm-dev
On 23 August 2017 at 17:15, Y Song <[hidden email]> wrote:

> The following is what I observed:
> Both Subtarget constructor and initAsmInfo will eventually create
> a MCSubtargetInfo, which calls InitMCProcessorInfo.
>
> void MCSubtargetInfo::InitMCProcessorInfo(StringRef CPU, StringRef FS) {
>   FeatureBits = getFeatures(CPU, FS, ProcDesc, ProcFeatures);
>   if (!CPU.empty())
>     CPUSchedModel = &getSchedModelForCPU(CPU);
>   else
>     CPUSchedModel = &MCSchedModel::GetDefaultSchedModel();
> }
>
> If you have -mcpu=help in your command line
> llc -march=<> -mcpu=help ...
>
> The help information will be printed out twice because getFeatures will printout
> the help info if both ProcDesc and ProcFeatures are not empty.
> This is not really elegent. What I am wondering is whether there are other
> side effect of this approach or not. If not, maybe I can live with this
> for a while....

I see what you mean, thanks for the clarification. That seems worth
filing a bug for on https://bugs.llvm.org/, even though it seems
pretty low impact.

Best,

Alex
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Subtarget Initialization in <ARCH>TargetMachine constructor

Matthias Braun via llvm-dev


On Wed, Aug 23, 2017 at 2:37 PM Alex Bradbury <[hidden email]> wrote:
On 23 August 2017 at 17:15, Y Song <[hidden email]> wrote:
> The following is what I observed:
> Both Subtarget constructor and initAsmInfo will eventually create
> a MCSubtargetInfo, which calls InitMCProcessorInfo.
>
> void MCSubtargetInfo::InitMCProcessorInfo(StringRef CPU, StringRef FS) {
>   FeatureBits = getFeatures(CPU, FS, ProcDesc, ProcFeatures);
>   if (!CPU.empty())
>     CPUSchedModel = &getSchedModelForCPU(CPU);
>   else
>     CPUSchedModel = &MCSchedModel::GetDefaultSchedModel();
> }
>
> If you have -mcpu=help in your command line
> llc -march=<> -mcpu=help ...
>
> The help information will be printed out twice because getFeatures will printout
> the help info if both ProcDesc and ProcFeatures are not empty.
> This is not really elegent. What I am wondering is whether there are other
> side effect of this approach or not. If not, maybe I can live with this
> for a while....

I see what you mean, thanks for the clarification. That seems worth
filing a bug for on https://bugs.llvm.org/, even though it seems
pretty low impact.


Yeah, this is pretty annoying, but hadn't been fixed yet.

-eric 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Subtarget Initialization in <ARCH>TargetMachine constructor

Matthias Braun via llvm-dev
On Fri, Aug 25, 2017 at 3:28 PM, Eric Christopher <[hidden email]> wrote:

>
>
> On Wed, Aug 23, 2017 at 2:37 PM Alex Bradbury <[hidden email]> wrote:
>>
>> On 23 August 2017 at 17:15, Y Song <[hidden email]> wrote:
>> > The following is what I observed:
>> > Both Subtarget constructor and initAsmInfo will eventually create
>> > a MCSubtargetInfo, which calls InitMCProcessorInfo.
>> >
>> > void MCSubtargetInfo::InitMCProcessorInfo(StringRef CPU, StringRef FS) {
>> >   FeatureBits = getFeatures(CPU, FS, ProcDesc, ProcFeatures);
>> >   if (!CPU.empty())
>> >     CPUSchedModel = &getSchedModelForCPU(CPU);
>> >   else
>> >     CPUSchedModel = &MCSchedModel::GetDefaultSchedModel();
>> > }
>> >
>> > If you have -mcpu=help in your command line
>> > llc -march=<> -mcpu=help ...
>> >
>> > The help information will be printed out twice because getFeatures will
>> > printout
>> > the help info if both ProcDesc and ProcFeatures are not empty.
>> > This is not really elegent. What I am wondering is whether there are
>> > other
>> > side effect of this approach or not. If not, maybe I can live with this
>> > for a while....
>>
>> I see what you mean, thanks for the clarification. That seems worth
>> filing a bug for on https://bugs.llvm.org/, even though it seems
>> pretty low impact.
>>
>
> Yeah, this is pretty annoying, but hadn't been fixed yet.

Thanks, Eric. Filed a lower priority bug
https://bugs.llvm.org/show_bug.cgi?id=34331
to keep the record.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev