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

[Alex Bradbury via llvm-dev]

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.


> 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