similar to: [LLVMdev] Problem with X86Subtarget::IsLegalToCallImmediateAddr()

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

On 2011-07-01 17:13, David Meyer wrote: > 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() ==

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

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

> Could be, echristo, bigcheese, would this be correct for Mach-O and COFF? bigcheese noted on IRC that the test crashes the COFF emitter. For some reason I am always getting movl $256, %eax ## imm = 0x100 calll *%eax on darwin already, so I guess you are right, the correct would be isTargetELF() && TM.getRelocationModel() == Reloc::Static; Please include a test

> 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

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

Hello, I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that is not support by LDD. Therefore even such a basic example cannot be built: /* s.c */ int f() { return 0; } /* t.c */ int f(); int _start() {

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

Hi! when reading X86Subtarget.h the methods seem a bit disordered, therefore I would propose to sort them new: -getTargetTriple() -cpu features (e.g. hasSSE1()) -os types (e.g. isTargetDarwin()) -object types (e.g. isTargetELF()) -callconv related functions (e.g. isTargetWin64(), consider renaming to isCallConvWin64(), getStackAlignment()) -pic functions perhaps my problem of generating elf

Hi All, I'm working on various cleanups and simplifications to the asmprinters. One thing that is driving me nuts is that the asmprinters currently "reverse engineer" a lot of information when printing an operand that isel had when it created it. I'm specifically talking about all the suffixes generated by isel, like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc. These

Rafael, I believe your example is not related to IsLegalToCallImmediateAddr. This is an example of calling to an immediate address: typedef int (*funcptr)(void); int main() { funcptr foo = (funcptr)0x100; foo(); } If IsLegalToCallImmedateAddr is true, this generates a call to absolute address 0x100: call 0x100 This requires a relocation of the value 0x100 - PC. (NOTE: this is NOT the

2011/10/17 David Meyer <pdox at google.com>: > Rafael, > > I believe your example is not related to IsLegalToCallImmediateAddr. > > This is an example of calling to an immediate address: > > typedef int (*funcptr)(void); > > int main() { >  funcptr foo = (funcptr)0x100; >  foo(); > } > > If IsLegalToCallImmedateAddr is true, this generates a call to

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

On Dec 5, 2013, at 3:19 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > > On Mon, Dec 2, 2013 at 4:25 PM, Andrew Trick <atrick at apple.com> wrote: > > On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > Hello llvm-dev, > > > > Following up on the "CodeGen Context" discussion that was started,

On Dec 5, 2013, at 4:47 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote: > We currently have something that looks like: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

Hi Evan, My apologies: I've been so excited on sharing the functionality that I forgot to review my patch! Evan Cheng wrote: > On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > > >> Hi everyone, >> >> Here's a patch that enables exception handling when jitting. I've >> copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may

Thought a bit more. There's also -mdynamic-no-pic. Not typically used these days, but is still there AFAIK. -Jim On Oct 21, 2011, at 4:05 PM, Eric Christopher wrote: > IIRC the kernel uses relocation model as static. > > -eric > > On Oct 21, 2011, at 3:57 PM, David Meyer wrote: > >> Eli, >> >> Hm. There's a test in (CodeGen/X86/call-imm.ll) which