similar to: Relocations used for PPC32 in non-PIC mode

Hal, I very well understand that LDD may not be in a good state for PPC32, and it would definitely need some improvements sooner or later. In fact I even submitted a patch adding a relocation to ldd just a few hours ago. However, this particular case is not related to LDD, it is a design issue and furthermore a regression in LLVM itself. I checked gcc, and neither does it try to use PLT and

On Apr 16, 2008, at 10:07 AM, Arnold Schwaighofer wrote: > Hello Dale, > > this is an updated version of the tail call optimization patch for > powerpc. could you have a look at it? > > i added code to support ppc64 (untested, will try to get access to > ppc64 on a friend's machine). > incorporated evan's formatting suggestions. ;) > > will run another round

Hello Dale, this is an updated version of the tail call optimization patch for powerpc. could you have a look at it? i added code to support ppc64 (untested, will try to get access to ppc64 on a friend's machine). incorporated evan's formatting suggestions. ;) will run another round of testing (llvm-test) on my powerpc g4/800 when i get the okay to commit. testing on this machine takes

On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com> wrote: > More nitpicks: > ... > No need for else here. :-) Done > SPDiff = (int)CallerMinReservedArea - (int)ParamSize; > > Just change last statement to > int SPDiff = (int)... Done > > +bool > +PPCTargetLowering::IsEligibleForTailCallOptimization(SDOperand Call, > +

On Sat, 17 Feb 2007, Nicolas Geoffray wrote: > Alright, thx Evan, that's what I did. > > Here are the final patches I think can be committed. I tried to separate > them into independent chunks, but I'm not sure how to do this in a good > way because of CVS and since everything is kind of related. Sorry for the delay, I applied the patches after some cleanups. Please

Rafael, I believe MachO can't represent this relocation, even in non-PIC mode. On my Mac, I tried compiling "call 256". I got: in section __TEXT,__text reloc 0: R_ABS reloc but no absolute symbol at target address I believe the correct thing to do is: isTargetELF() && TM.getRelocationModel() == Reloc::Static This will do the right thing on ELF, and the right thing on

Evan Cheng wrote: > 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. > Alright, thx Evan, that's

On Apr 22, 2008, at 4:58 AM, Arnold Schwaighofer wrote: > On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com> > wrote: >> More nitpicks: >> ... >> No need for else here. :-) > Done >> SPDiff = (int)CallerMinReservedArea - (int)ParamSize; >> >> Just change last statement to >> int SPDiff = (int)... > Done >>

Hi Chris, Chris Lattner wrote: > Sorry for the delay, > > No problem. Plus the reviewing may have taken some time. So thx a lot for committing. I talked to Jim who said he wanted to commit his changes before mine -- I hope everything's Ok. > I applied the patches after some cleanups. Please keep code within 80 > columns, please don't use nested ?: expressions without

On Fri, 2008-06-06 at 17:08 +0100, Rafael Espindola wrote: > 2008/6/6 Anton Korobeynikov <asl at math.spbu.ru>: > > Hello, Rafael > > > > Awesome! But... -ENOPATCH :( > > Attached now. Hi Rafael, Thanks a lot for working on this! I have one question about the patch; why did you choose too add a new enum, PICCallStyle, instead of reusing (possibly with some

On Jun 6, 2008, at 11:55 AM, Dan Gohman wrote: > On Fri, 2008-06-06 at 17:08 +0100, Rafael Espindola wrote: >> 2008/6/6 Anton Korobeynikov <asl at math.spbu.ru>: >>> Hello, Rafael >>> >>> Awesome! But... -ENOPATCH :( >> >> Attached now. > > Hi Rafael, > > Thanks a lot for working on this! > > I have one question about the

It seems that the || should be && here? /// IsLegalToCallImmediateAddr - Return true if the subtarget allows calls /// to immediate address. bool X86Subtarget::IsLegalToCallImmediateAddr(const TargetMachine &TM) const { if (Is64Bit) return false; return isTargetELF() || TM.getRelocationModel() == Reloc::Static; } For example, if you are doing ELF PIC (i.e. for a shared

Rafael, Use this bitcode: define i32 @main() nounwind { entry: %call = tail call i32 inttoptr (i64 256 to i32 ()*)() nounwind ret i32 0 } And this command: $ llc -mtriple "i686-linux-gnu" test.ll -o test.s -filetype=asm -relocation-model=pic - pdox

> And this command: > > $ llc -mtriple "i686-linux-gnu" test.ll -o test.s -filetype=asm > -relocation-model=pic I can reproduce it now. Sorry, I was using a test returning void and we don't have tail call of immediate. My impression in that the right fix would be to just remove the "isTargetELF()". It would make the function correct for ELF and not less

2011/10/21 David Meyer <pdox at google.com>> Rafael, > > I believe MachO can't represent this relocation, even in non-PIC mode. > On my Mac, I tried compiling "call 256". I got: I think PIC is just the default (the kernel being non-PIC for example), but I am not sure. > in section __TEXT,__text reloc 0: R_ABS reloc but no absolute symbol > at target address

On Sun, 25 Feb 2007, Nicolas Geoffray wrote: > No problem. Plus the reviewing may have taken some time. So thx a lot > for committing. I talked to Jim who said > he wanted to commit his changes before mine -- I hope everything's Ok. There is one significant bug that fell out from this, which caused some macho function calls to be compiled with ELF ABI semantics. I checked in this

Hi Dean, I have a question for 32-bit platforms. I see in the code that you used the following in compiler-rt/trunk/lib/xray/xray_interface_internal.h : struct XRaySledEntry { uint64_t Address; uint64_t Function; unsigned char Kind; unsigned char AlwaysInstrument; unsigned char Padding[14]; // Need 32 bytes }; And the peer code in llvm/trunk/lib/Target/X86/X86MCInstLower.cpp : void

Hi all, I am currently working on AMDGPU inline assembly and encountered problem with naming clobber registers in asm constraints. It looks like by default LLVM tries to match register specified in constraint to register name of register definition in .td file but not to the AsmName for this register. For example if we have register definition: def MYReg0 : Register<"r0", 0>;

I've attached a less-hackish implementation of this. This includes the following modifications: - getSupportsOverlappingAliases() method on TargetMachine which returns whether the target supports multiple symbols to the same object. This returns false in the superclass and needs to be explicitly overridden for each target to enable it. - An implementation of this method in

Hi Everyone, Chris suggested[1] I should ask for feedback as to whether this is a desired feature before I put too much effort into it, so here goes: I would like to be able to export a symbol that is inside an LLVM structure. This is possible on ELF targets[2], and the attached proof- of-concept patch to AsmWriter makes it work (although in a hackish way that I am NOT suggesting be