similar to: [LLVMdev] Subtarget class

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

Hi Chris, Chris Lattner wrote: >> 2) Line 369 of PPCInstrInfo.td, we declare the non-callee saved registers. >> However, Linux and Darwin do not have the same set >> of non-callee saved registers. I don't know how to make the if(isDarwin) test >> in here >> > > Take a look at ARM/ARMRegisterInfo.td for an example of this I tried to define Defs just

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

On Sat, May 7, 2011 at 4:17 AM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi, Justin > > Thansk, but I have a little concern though. I saw Chiou mentioned the > compatibility issue of PTX on the mailing list. > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038654.html > > In my PTX.td patch, > > def FeaturePTX23 : SubtargetFeature<"ptx23",

Hi, Justin Thansk, but I have a little concern though. I saw Chiou mentioned the compatibility issue of PTX on the mailing list. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038654.html In my PTX.td patch, def FeaturePTX23 : SubtargetFeature<"ptx23", "PTXVersion", PTX_VERSION_2_3", "Use PTX Language Version

Hi All, I've gotten a few notes over the last few months and also given some of the recent changes to various backends to "update" the default tunings for a generic processor it made me think again about adding support for tuning to a processor rather than generating processor specific code - hence, mtune. I hope this is rather uncontroversial, but happy to discuss at length if

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

On 04/01/2013 12:31 PM, Chandler Carruth wrote: > On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com > <mailto:nrotem at apple.com>> wrote: > > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if > the attributes changed). Do you have another solution in mind ?

I think the easiest thing for you to do is to define a separate CALL instruction with a different set of Defs. This instruction should only be selected when the predicate isMacho is true. Also update PPCRegisterInfo.cpp getCalleeSavedRegs() to return a different list when subtarget->isMachoABI() is true. Evan On Feb 14, 2007, at 7:19 AM, Nicolas Geoffray wrote: > Hi Chris, >

Hi all, I have a sample test case : $ cat 1.c int foo(int x, int y){ int z = x + y; return z/2; } I tried to get its IR form with clang providing subtarget feature as mmx for target x86_64 $ clang -O3 -mmmx 1.c -S -emit-llvm in the IR generated i can see the subtarget-features as function attribute : "target-features"="+mmx" In the SelectionDAG phase in file

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,

[resending to correct llvm-dev address] Hi, I’d like to start enabling the loop data prefetch pass for Cyclone (an ARM64 subtarget). AFAICT, you can’t really add passes specifically to a subtarget but only to a target. This makes sense because in the new world, you could have different subtargets per function. I just want to make sure my understanding is correct. My plan is to add the pass

Hi, while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations). I would like to ask what the ideas are on how this should be done best. Some

The target description .td files are allowed to change the default allocation order on a register class by overriding the allocation_order_begin() and allocation_order_end() methods on TargetRegisterClass. Previously, this was used all the time to filter out stack and frame pointers and other reserved registers. I was able to remove most of these custom allocation orders in the tree because the

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

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.

I am working on an LLVM backend for the AVR architecture, and am having troubles working with the codegen layer, trying to get around the quirks of the binary encodings of the AVR ISR. There are several different families of AVR microcontrollers, each with a minimum 'core' instruction set. Each family builds upon (or removes) the core ISR with more instructions or different encodings. My

Hello, I have written following code to check each register if it is used by machineFunction or not : MachineRegisterInfo *MRI = &MF.getRegInfo(); TargetRegisterInfo *TRI = (TargetRegisterInfo *)MF.getSubtarget().getRegisterInfo(); const TargetMachine &TM = MF.getTarget(); const MCRegisterInfo *MCRI = TM.getMCRegisterInfo(); DEBUG(dbgs() << "Function Name : " <<

Hello, I'm implementing a port of LLVM for PowerPC VLE. It's a compressed instruction set similar to mips16 and ARM Thumb. Instruction encoding (VLE/non-vle) is selected for a given memory region by an attribute in a memory area descriptor. Targets supporting this that I know of are all bare-metal (so powerpc-none-elf). I'm trying to implement ELF support right now. VLE ELF files

Dear developers! I have one problem and two options for its solution: • I can make a simple pass which will specify the subtarget instruction set (ARM or Thumb) for a particular instruction (or a basic block) LLVM intermediate representation OR • I can add a special pass to arm backend which will do the same (specify subtarget instruction set (ARM or Thumb) for a particular