similar to: [LLVMdev] Linux/ppc backend

On Fri, 2 Feb 2007, Nicolas Geoffray wrote: > I have almost completed the implementation of a linux/ppc backend in llvm. Cool! > There were a few things to modify in > lib/Target/PowerPC with a lot of "if (!isDarwin)". Some meta comments: 1. Please don't change PPC -> llvmPPC. I assume that you did this because PPC is a #define in some system header. Please

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

Nicolas, Would you point me to the Linux/PPC ABI documents you are using so I can better judge what your restrictions are? These changes also have an effect on debugging and exception handling. Cheers, -- Jim On 2-Feb-07, at 08:58 AM, Nicolas Geoffray wrote: > Hi everyone, > > I have almost completed the implementation of a linux/ppc backend > in llvm. There were a few

Hi Jim, I didn't use any documents, but intensively looked at gcc's output. I think this document: http://refspecs.freestandards.org/elf/elfspec_ppc.pdf is the last specification of the ABI. Cheers, Nicolas Jim Laskey wrote: > Nicolas, > > Would you point me to the Linux/PPC ABI documents you are using so I > can better judge what your restrictions are? These changes

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'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

On Fri, 12 Jan 2007, Nicolas Geoffray wrote: > I'm currently implementing a linux/ppc target in llvm. The abis between cool > Darwin/ppc and linux/ppc are different and I'm running into problems > with vararg calls. ok > Before a variadic method is called, an extra instruction must be > executed (which is creqv 6, 6, 6). This instruction is not necessary in >

Hi Chris, Chris Lattner wrote: > On Fri, 2 Feb 2007, Nicolas Geoffray wrote: > > > Some meta comments: > > 1. Please don't change PPC -> llvmPPC. I assume that you did this because > PPC is a #define in some system header. Please just add a '#undef PPC' > where appropriate to make this unneeded. > OK > 2. The X86 backend has the

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? -

----- Original Message ----- > From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com> > To: "David Wiberg" <dwiberg at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, July 30, 2014 2:29:22 PM > Subject: Re: [LLVMdev] [PowerPC] ABI questions > > Hi David, > > > I'm trying to understand which ABIs are supported in the

On Sun, 4 Feb 2007, Nicolas Geoffray wrote: >> 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

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it:

You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See

Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:

Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and

Cool, that worked. New patch attached... Cheers, Gary Evan Cheng wrote: > Just cast both values to const TargetRegisterClass*. > > Evan > > On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > > Evan Cheng wrote: > > > How about? > > > > > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > > > &PPC:G8RCRegClass; >

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)