search for: getrelocationmodel

...s not even desired, and it is likely just an overlooked regression. If you check the original code, PLT was only meant to be used with PIC code: https://reviews.llvm.org/rL213427#C65598OL3360. Note, that there are two places covering the PPCII::MO_PLT_OR_STUB assignment, which are both guarded with getRelocationModel check. Now let's look at https://reviews.llvm.org/rL273499#C65598OL4294 and https://reviews.llvm.org/rL273595#C65598OL4316. For some unknown reason these two commits silently removed -fno-pic handling, and effectively enforced PLT use. As a result they broke the compatibility with linkers not...

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 other formats. This may have been the original intent. - pdox

...regression. If you check the original code, PLT was only meant to be used with PIC code: https://reviews.llvm.org/rL213427#C65598OL3360 <https://reviews.llvm.org/rL213427#C65598OL3360>. Note, that there are two places covering the PPCII::MO_PLT_OR_STUB assignment, which are both guarded with getRelocationModel check. >> >> Now let's look at https://reviews.llvm.org/rL273499#C65598OL4294 <https://reviews.llvm.org/rL273499#C65598OL4294> and https://reviews.llvm.org/rL273595#C65598OL4316 <https://reviews.llvm.org/rL273595#C65598OL4316>. For some unknown reason these two commits...

Has anyone experimented with generating non-PIC for MIPS64 and the n64 ABI? Currently MipsISelLowering.cpp uses conditions like: if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { } around any PIC code generation. Is generating non-PIC just untested, or is it known not to work? I can't find any discussion of it anywhere. I ran into this when trying to see why --relocation-model=static had no effect on the output. I'm game to test it...

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 library), it is not valid to use a call immediate. - David

...;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 > > 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 other > formats. This may have been the original intent. Could be, echristo, bigcheese, would this be correct for Mach-O and COFF? > - pdox > Cheers, Rafael

On Mon, 16 Jun 2008, Gary Benson wrote: > When you genetate code on PowerPC you need to explicitly invalidate > the instruction cache to force the processor to reread it. In LLVM > there is code to do this for function stubs on Macintosh, but not > for other platforms and not for JITted code generally. Applied, thanks!

...CCodeEmitter.cpp (working copy) @@ -80,10 +80,6 @@ return new PPCCodeEmitter(TM, MCE); } -#ifdef __APPLE__ -extern "C" void sys_icache_invalidate(const void *Addr, size_t len); -#endif - bool PPCCodeEmitter::runOnMachineFunction(MachineFunction &MF) { assert((MF.getTarget().getRelocationModel() != Reloc::Default || MF.getTarget().getRelocationModel() != Reloc::Static) && Index: lib/Target/PowerPC/PPCJITInfo.h =================================================================== --- lib/Target/PowerPC/PPCJITInfo.h (revision 52391) +++ lib/Target/PowerPC/PPCJITInfo.h (wor...

...e, "$non_lazy_ptr"); } } else { printSuffixedName(Name, "$non_lazy_ptr"); } where shouldPrintStub is: static inline bool shouldPrintStub(TargetMachine &TM, const X86Subtarget* ST) { return ST->isPICStyleStub() && TM.getRelocationModel() != Reloc::Static; } This is really redundant with isel, because isel also needs to know exactly which GV references go through a stub so that it isels the access correctly. My proposed fix for this is to add an 'unsigned char' slot to MachineOperand that holds a target-specific...

...ent:* 29 April 2014 22:35 > *To:* llvmdev at cs.uiuc.edu > *Subject:* [LLVMdev] MIPS n64 ABI and non-PIC > > > > Has anyone experimented with generating non-PIC for MIPS64 and the n64 > ABI? Currently MipsISelLowering.cpp uses conditions like: > > if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { > > } > > > > around any PIC code generation. Is generating non-PIC just untested, or > is it known not to work? I can't find any discussion of it anywhere. I ran > into this when trying to see why --relocation-model=static had no effect...

...p;MO); > + > + void getAnalysisUsage(AnalysisUsage &AU) const { > + AU.addRequired<MachineModuleInfo>(); > + MachineFunctionPass::getAnalysisUsage(AU); > + } > > public: > static char ID; > @@ -82,6 +87,8 @@ > assert((MF.getTarget().getRelocationModel() != Reloc::Default || > MF.getTarget().getRelocationModel() != Reloc::Static) && > "JIT relocation model must be set to static or default!"); > + > + MCE.setModuleInfo(&getAnalysis<MachineModuleInfo>()); > do { > MovePCtoL...

...AnalysisUsage(AnalysisUsage &AU) const { >> + AU.addRequired<MachineModuleInfo>(); >> + MachineFunctionPass::getAnalysisUsage(AU); >> + } >> >> public: >> static char ID; >> @@ -82,6 +87,8 @@ >> assert((MF.getTarget().getRelocationModel() != Reloc::Default || >> MF.getTarget().getRelocationModel() != Reloc::Static) && >> "JIT relocation model must be set to static or default!"); >> + >> + MCE.setModuleInfo(&getAnalysis<MachineModuleInfo>()); >> do {...

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 need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

...lobalPrefix() << getFunctionNumber() - << '_' << JTI << '_' << MO2.getImm() - << "_set_" << MBB->getNumber(); + O << prefix.str() << "_set_" << MBB->getNumber(); else if (TM.getRelocationModel() == Reloc::PIC_) { printBasicBlockLabel(MBB, false, false, false); // If the arch uses custom Jump Table directives, don't calc relative to JT if (!TAI->getJumpTableDirective()) - O << '-' << TAI->getPrivateGlobalPrefix() << "JT...

Hi all, When you genetate code on PowerPC you need to explicitly invalidate the instruction cache to force the processor to reread it. In LLVM there is code to do this for function stubs on Macintosh, but not for other platforms and not for JITted code generally. The attached patch adds support for GNU platforms, but I can't figure out a nice way to call it for all generated code. Can

...&MO); > + > + void getAnalysisUsage(AnalysisUsage &AU) const { > + AU.addRequired<MachineModuleInfo>(); > + MachineFunctionPass::getAnalysisUsage(AU); > + } > > public: > static char ID; > @@ -82,6 +88,8 @@ > assert((MF.getTarget().getRelocationModel() != Reloc::Default || > MF.getTarget().getRelocationModel() != Reloc::Static) && > "JIT relocation model must be set to static or default!"); > + > + MCE.setModuleInfo(&getAnalysis<MachineModuleInfo>()); > do { > MovePCtoLROff...

The current rule is: /// IsLegalToCallImmediateAddr - Return true if the subtarget allows calls /// to immediate address. bool X86Subtarget::IsLegalToCallImmediateAddr(const TargetMachine &TM) const { if (In64BitMode) return false; return isTargetELF() || TM.getRelocationModel() == Reloc::Static; } But this is not doing the correct thing for ELF PIC. The straight-forward way to fix this is to change the || to &&. However, this would make the function always return false for other object file formats. I was under the impression only ELF had the ability to emit t...

...&& 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 library), it > is not valid to use a call immediate. I think that on 32 bits it is legal, just not profitable. I tried compiling two .c files without -fPIC: --------------- int g(void) { ret...

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