search for: getsubtargetimpl

...FPMath, defined in CommandFlags.h). 2. Replace usages of TargetOptions::UnsafeFPMath with calls to a function which gets the value of attribute “unsafe-fp-math” in the IR. 3. Stringify function attribute “unsafe-fp-math” and append it to the string that is used as the lookup key in TargetMachine::getSubtargetImpl(const Function&). Also, pass the function attribute to the subtarget constructors that need it to construct itself (e.g., ARM) or construct one of the backend objects (e.g., X86, which needs it in the constructor of X86TargetLowering). 4. In MachineFunction’s constructor, call TargetMachine::g...

...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,...

I've been investigating what is needed to ensure command line options are passed to the backend codegen passes during LTO and enable compiling different functions in a module with different command line options (see the links below for previous discussions). http://thread.gmane.org/gmane.comp.compilers.llvm.devel/78855 http://thread.gmane.org/gmane.comp.compilers.llvm.devel/80456 The command

...TTI and various other backend hooks rather than any code gen specific ones. Simple right? :) I'm happy to elaborate here, but I believe the work is relatively straight forward if a lot of typing. Every step there is likely to be a lot more complicated, but similar to the getSubtarget<>/getSubtargetImpl changes it should be very easy to do on any particular backend and fan out support there. Just make sure that clang knows which targets do and don't support the flag. Happy to help or review work here. Thanks! -eric -------------- next part -------------- An HTML attachment was scrubbed... U...

Hi all, As of r232885 I've removed the argument-less TargetMachine::getSubtarget and TargetMachine::getSubtargetImpl. For the targets that aren't completely independent of this I've gone ahead and left a non-virtual version of the function in the target specific TargetMachine. What this means in practice is that those targets can only use a bare getSubtarget call in their target specific code, and should...

...erstand 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 enab...

...> > My best advice to you is don't try to swim upstream. The Liskov substitution principle for register classes is deeply ingrained in the LLVM register allocators. > > /jakob > I guess I can just fix the problem with: if ((RC == &Mips::CPU16RegsRegClass) && !TM.getSubtargetImpl()->inMips16Mode()) RC = &Mips::CPURegsRegClass;

...> 2. Replace usages of TargetOptions::UnsafeFPMath with calls to a > function which gets the value of attribute “unsafe-fp-math” in the > IR. > > 3. Stringify function attribute “unsafe-fp-math” and append it to the > string that is used as the lookup key in > TargetMachine::getSubtargetImpl(const Function&). Also, pass the > function attribute to the subtarget constructors that need it to > construct itself (e.g., ARM) or construct one of the backend objects > (e.g., X86, which needs it in the constructor of X86TargetLowering). > > 4. In MachineFunction’s construct...

...is don't try to swim upstream. The Liskov substitution principle for register classes is deeply ingrained in the LLVM register allocators. >> >> /jakob >> > I guess I can just fix the problem with: > > if ((RC == &Mips::CPU16RegsRegClass) && > !TM.getSubtargetImpl()->inMips16Mode()) > RC = &Mips::CPURegsRegClass; Can I ask what concrete problem you're seeing? The ARM backend has exactly the same issue: in Thumb1 mode (similar to MIPS16), not all GPRs are available. Accordingly, getMinimalPhysRegClass() returns tGPR (Thumb GPR) for those...

...0). I have added a subtarget feature "vle", similar to Altivec, SPE, VSX etc and I'm enabling this feature for appropriate CPUs. Now, functions that are compiled with "vle" feature should go into a different text section (text_vle). I can see that TargetMachine has a method getSubtargetImpl which can be overridden for the implementation and it can return different subtargets for different function attributes. What I'm struggling with is connecting it to section selection; in MCObjectFileInfo::initELFMCObjectFileInfo a default text section is created but since here section should b...

...LVM module flags metadata. But there is an another issue in assembler. In current LLVM design, there is no mechanism to extract info from IR before AsmBackend construction, so I use some little weird approach to init target-abi option before construct AsmBackend[1] or reassign target-abi option in getSubtargetImpl and do some hack in backend[2]. 1. https://reviews.llvm.org/D72245#change-sHyISc6hOqcy (see llc.cpp) 2. https://reviews.llvm.org/D72246 (see RISCVAsmBackend.h) I think [1] and [2] are not good enough, the other ideals like 3. encode target abi info in triple name. ex. riscv64-unknown-elf-lp64d 4...

...gt;> <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 concer...

...Reloc::Model RM, CodeModel::Model CM, CodeGenOpt::Level OL) - : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, false), + : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, Triple(TT).getArch()) DL(computeDataLayout(*getSubtargetImpl())), InstrInfo(*this), -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pk...

...But there is an another issue in assembler. In current LLVM design, there >> is no mechanism to extract info from IR before AsmBackend construction, so >> I use some little weird approach to init target-abi option before construct >> AsmBackend[1] or reassign target-abi option in getSubtargetImpl and do some >> hack in backend[2]. >> >> 1. https://reviews.llvm.org/D72245#change-sHyISc6hOqcy (see llc.cpp) >> 2. https://reviews.llvm.org/D72246 (see RISCVAsmBackend.h) >> >> I think [1] and [2] are not good enough, the other ideals like >> >> 3. e...

...flags metadata. > > But there is an another issue in assembler. In current LLVM design, there is no mechanism to extract info from IR before AsmBackend construction, so I use some little weird approach to init target-abi option before construct AsmBackend[1] or reassign target-abi option in getSubtargetImpl and do some hack in backend[2]. > > 1. https://reviews.llvm.org/D72245#change-sHyISc6hOqcy <https://reviews.llvm.org/D72245#change-sHyISc6hOqcy> (see llc.cpp) > 2. https://reviews.llvm.org/D72246 <https://reviews.llvm.org/D72246> (see RISCVAsmBackend.h) > > I think [1]...

...ttributes stored to the bitcode in step 2. Function::hasFnAttribute can be called directly (for example, NoNaNsFPMath in the patch), if the default value is known to be "false". I also made the following changes in the patch: 1. In the constructor of MachineFunction, call the version of getSubtargetImpl that takes a Function parameter, so that it gets the Subtarget specific to the Function being compiled. 2. Change ARMTargetMachine::SubtargetMap to be a DenseMap<Function*, unique_ptr<ARMSubtarget>>. This is just a temporary change to ease debugging and should be reverted to a StringMap...

...are module-level or function level attributes or whether they affect subtarget creation, etc. I'll probably start new threads on llvm-dev soon to discuss the option categories individually to have a more focused discussion. A couple of other questions: - Subtarget lookup in XXXTargetMachine::getSubtargetImpl(const Function &F) seems a bit error-prone to me. If you add an option that is needed for subtargert creation as an attribute to Function, but forget to add it to the key that is used to search SubtargetMap, it can incorrectly return a cached subtarget when it should be creating a new one. Woul...

...:hasFnAttribute can be called directly (for example, NoNaNsFPMath >> in the patch), if the default value is known to be "false". >> >> I also made the following changes in the patch: >> >> 1. In the constructor of MachineFunction, call the version of >> getSubtargetImpl that takes a Function parameter, so that it gets the >> Subtarget specific to the Function being compiled. >> 2. Change ARMTargetMachine::SubtargetMap to be a DenseMap<Function*, >> unique_ptr<ARMSubtarget>>. This is just a temporary change to ease >> debugging a...

...etadata. >> >> But there is an another issue in assembler. In current LLVM design, there is no mechanism to extract info from IR before AsmBackend construction, so I use some little weird approach to init target-abi option before construct AsmBackend[1] or reassign target-abi option in getSubtargetImpl and do some hack in backend[2]. >> >> 1. https://reviews.llvm.org/D72245#change-sHyISc6hOqcy <https://reviews.llvm.org/D72245#change-sHyISc6hOqcy> (see llc.cpp) >> 2. https://reviews.llvm.org/D72246 <https://reviews.llvm.org/D72246> (see RISCVAsmBackend.h) >> &...

On May 14, 2012, at 2:28 PM, reed kotler wrote: > I'm not using getMinimalPhysRegClass. Some target independent code is using it. Probably PEI. > It makes trouble for us and I would like to submit a patch to make it a virtual function so that I can override it and make it meaningful for Mips, as long as this method still exists. > > I want to add another register class for