llvm dev - Aug 2017 - Subtarget Initialization in <ARCH>TargetMachine constructor

Thanks, Alex. See my comments below.

On Wed, Aug 23, 2017 at 12:59 AM, Alex Bradbury <asb at asbradbury.org>
wrote:
> On 22 August 2017 at 23:39, Y Song via llvm-dev <llvm-dev at
lists.llvm.org> 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

On 23 August 2017 at 17:15, Y Song <ys114321 at gmail.com>
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

On Wed, Aug 23, 2017 at 2:37 PM Alex Bradbury <asb at asbradbury.org>
wrote:
> On 23 August 2017 at 17:15, Y Song <ys114321 at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170825/929ddae1/attachment.html>