search for: ppcsubtarget

...,F13, V0,V1,V2,V3,V4,V5,V6,V7,V8,V9,V10,V11,V12,V13,V14,V15,V16,V17,V18,V19, LR,CTR, CR0,CR1,CR5,CR6,CR7} GPRClass::iterator GPRClass::allocation_order_begin(const MachineFunction &MF) const { const TargetMachine &TM = MF.getTarget(); const PPCSubtarget &Subtarget = TM.getSubtarget<PPCSubtarget>(); if (Subtarget.isMachoABI()){ return Defs_Macho; } else { return Defs_ELF; } } GPRClass::iterator GPRClass::allocation_order_end(const MachineFunction &MF) const { const TargetMachine &am...

I'm having some troubles building LLVM 3.3 (previously I was using 3.2). I'm getting a lot of errors in the various architecture support: In file included from PPCFrameLowering.h:17:0, from PPCTargetMachine.h:17, from PPCSelectionDAGInfo.cpp:15: PPCSubtarget.h:60:49: error: expected class-name before ‘{’ token PPCSubtarget.h:196:30: error: ‘RegClassVector’ has not been declared In file included from AArch64Subtarget.cpp:14:0: AArch64Subtarget.h:29:57: error: expected class-name before ‘{’ token PPCFrameLowering.h: In member function ‘virtual const ll...

Hi all, I'm trying to understand which ABIs are supported in the PowerPC backend and I'm getting a bit confused. Here's what I've gathered so far alongside with some questions. - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI. - The CodeGenerator documentation claims that the AIX PowerPC ABI is followed (with some deviations). Is this refering to the DarwinABI? - In a recent commit a TargetABI value and enumeration was added to PPCSubtarget which contains PPC_ABI_UNKNOWN, PP...

...riate to make this unneeded. 2. The X86 backend has the unfortunate habit of saying "if !darwin" "if !cygwin" etc. Most of the changes you've made are actually ABI related changes, not OS-specific changes. As such, I'd prefer it if you added two methods to PPCSubtarget: isMachoABI() and isELF_ABI() (or whatever is the right name of the ABI that linux uses) and use those instead. 3. Please split up the patch into independent chunks for easier review. This will make it much more likely that your pieces will be applied in a timely fashion :). This will...

...,V8,V9,V10,V11,V12,V13,V14,V15,V16,V17,V18,V19, > LR,CTR, > CR0,CR1,CR5,CR6,CR7} > > GPRClass::iterator > GPRClass::allocation_order_begin(const MachineFunction &MF) > const { > const TargetMachine &TM = MF.getTarget(); > const PPCSubtarget &Subtarget = TM.getSubtarget<PPCSubtarget>(); > if (Subtarget.isMachoABI()){ > return Defs_Macho; > } else { > return Defs_ELF; > } > } > > GPRClass::iterator > GPRClass::allocation_order_end(const MachineFunction &a...

...rchangably with "SVR4 ABI". > > ELFv1 is a recently introduced term to refer to what was previously > just called the ELF ABI (or equivalently SVR4 ABI); it is now used > to refer to the *old* variant of the ELF ABI as opposed to the new > one (ELFv2). > > > - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI. > > - The CodeGenerator documentation claims that the AIX PowerPC ABI > > is > > followed (with some deviations). Is this refering to the DarwinABI? > > No, that's the ELFv1 ABI. > > > - In a recent commit a Targe...

Hi everyone, I have almost completed the implementation of a linux/ppc backend in llvm. There were a few things to modify in lib/Target/PowerPC with a lot of "if (!isDarwin)". There are some places where I need help before saying the port is complete. I attached the diff file as a reference 1) In order to generate a creqv instruction before a vararg call, I created a new

...uot;>; def : Processor<"pwr7", G5Itineraries, [DirectivePwr7, FeatureAltivec, FeatureMFOCRF, FeatureFSqrt, FeatureSTFIWX, FeatureISEL, Feature64Bit /*, Feature64BitRegs */]>; During compilation the subtarget class (such as PPCSubtarget) is instantiated with the strings obtained from -mcpu and -mattr. ParseSubtargetFeatures then uses the -mcpu and -mattr values to determine which features to use for code generation. What seems problematic is that -mattr is the only way that the static features of the target processor can be overr...

...my implementation I'm trying to reuse as much as possible from the existing PPC backend. My first goal is to target a VLE only core and my strategy so far has been to mark my VLE instructions with a predicate to require VLE support from the sub target. Example: def HasVLE : Predicate<"PPCSubTarget->hasVLE()">, AssemblerPredicate<"FeatureVLE", "VLE Instruction set">; let Predicates = [HasVLE] in { If I have understood this correct the predicate will work for CodeGen and the assembler but not for the disassembler. This has worked for the instructions adde...

...then ... > else if (os == darwin && ppc64) then ... This is inefficient :) > 3) Create a new subtarget (but does it worth it? considering that the > difference between the 2 abis is minor) There is already a subtarget. In the call lowering code, just do something like: if (!PPCSubTarget->isDarwin()) ... insert creq here ... -Chris -- http://nondot.org/sabre/ http://llvm.org/

...[DirectivePwr7, FeatureAltivec, > > FeatureMFOCRF, FeatureFSqrt, FeatureSTFIWX, > > FeatureISEL, Feature64Bit /*, Feature64BitRegs > > */]>; > > > > During compilation the subtarget class (such as PPCSubtarget) is > > instantiated with the strings obtained from -mcpu and -mattr. > > ParseSubtargetFeatures then uses the -mcpu and -mattr values to > > determine which features to use for code generation. > > > > What seems problematic is that -mattr is the only way that the st...

Hi all, I'm currently implementing a linux/ppc target in llvm. The abis between Darwin/ppc and linux/ppc are different and I'm running into problems with vararg calls. Before a variadic method is called, an extra instruction must be executed (which is creqv 6, 6, 6). This instruction is not necessary in Darwin/ppc. I looked into the PowerPC target implementation and the code generation

...5Itineraries, > [DirectivePwr7, FeatureAltivec, > FeatureMFOCRF, FeatureFSqrt, FeatureSTFIWX, > FeatureISEL, Feature64Bit /*, Feature64BitRegs > */]>; > > During compilation the subtarget class (such as PPCSubtarget) is > instantiated with the strings obtained from -mcpu and -mattr. > ParseSubtargetFeatures then uses the -mcpu and -mattr values to > determine which features to use for code generation. > > What seems problematic is that -mattr is the only way that the static > features of the...

...gt; OK > 2. The X86 backend has the unfortunate habit of saying "if !darwin" "if > !cygwin" etc. Most of the changes you've made are actually ABI related > changes, not OS-specific changes. As such, I'd prefer it if you added > two methods to PPCSubtarget: isMachoABI() and isELF_ABI() (or whatever > is the right name of the ABI that linux uses) and use those instead. > Well all of the changes are ABI related. In fact, could you give me an example of what is os-specific and not abi-specific? I'm not sure. > 3. Please split up the...

...nterchangably with "SVR4 ABI". > > ELFv1 is a recently introduced term to refer to what was previously > just called the ELF ABI (or equivalently SVR4 ABI); it is now used > to refer to the *old* variant of the ELF ABI as opposed to the new > one (ELFv2). > >> - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI. >> - The CodeGenerator documentation claims that the AIX PowerPC ABI is >> followed (with some deviations). Is this refering to the DarwinABI? > > No, that's the ELFv1 ABI. > But it describes both 64-bit and 32-bit linkage are...

...gt; > > FeatureMFOCRF, FeatureFSqrt, FeatureSTFIWX, > > > > FeatureISEL, Feature64Bit /*, Feature64BitRegs > > > > */]>; > > > > > > > > During compilation the subtarget class (such as PPCSubtarget) is > > > > instantiated with the strings obtained from -mcpu and -mattr. > > > > ParseSubtargetFeatures then uses the -mcpu and -mattr values to > > > > determine which features to use for code generation. > > > > > > > > What seems prob...

...7, FeatureAltivec, > > > FeatureMFOCRF, FeatureFSqrt, FeatureSTFIWX, > > > FeatureISEL, Feature64Bit /*, Feature64BitRegs > > > */]>; > > > > > > During compilation the subtarget class (such as PPCSubtarget) is > > > instantiated with the strings obtained from -mcpu and -mattr. > > > ParseSubtargetFeatures then uses the -mcpu and -mattr values to > > > determine which features to use for code generation. > > > > > > What seems problematic is that -mattr is...

...calling some method is the targets TargetRegisterInfo subclass. These methods generally look something like this: > > const uint32_t * > PPCRegisterInfo::getCallPreservedMask(const MachineFunction &MF, > CallingConv::ID CC) const { > const PPCSubtarget &Subtarget = MF.getSubtarget<PPCSubtarget>(); > ... > return TM.isPPC64() ? (Subtarget.hasAltivec() ? CSR_SVR464_Altivec_RegMask > : CSR_SVR464_RegMask) > : (Subtarget.hasAltivec() ? CSR_SVR432_Altivec_R...

...calling some method is the targets TargetRegisterInfo subclass. These methods generally look something like this: > > const uint32_t * > PPCRegisterInfo::getCallPreservedMask(const MachineFunction &MF, > CallingConv::ID CC) const { > const PPCSubtarget &Subtarget = MF.getSubtarget<PPCSubtarget>(); > ... > return TM.isPPC64() ? (Subtarget.hasAltivec() ? CSR_SVR464_Altivec_RegMask > : CSR_SVR464_RegMask) > : (Subtarget.hasAltivec() ? CSR_SVR432_Altivec_R...

...ing some method is the targets TargetRegisterInfo subclass. > These methods generally look something like this: > > const uint32_t * > PPCRegisterInfo::getCallPreservedMask(const MachineFunction &MF, > CallingConv::ID CC) const { > const PPCSubtarget &Subtarget = MF.getSubtarget<PPCSubtarget>(); > ... > return TM.isPPC64() ? (Subtarget.hasAltivec() ? > CSR_SVR464_Altivec_RegMask > : CSR_SVR464_RegMask) > : (Subtarget.hasAltivec() ? > CSR_SVR432...