search for: codemodel

Hi, We were just debugging a sporadic crash the other day, when we noticed that RIP-relative addressing was being used in a JumpTable, even when code and data were well over 4G apart. This is confusing, because we picked CodeModel::Large, and expected this to be taken care of. Isn't that what gcc would do given a Large CodeModel? The default Relocation Model, Reloc::Default, folds into Reloc::PIC_ in most cases. However, if we explicitly specify Reloc::Static, our program should work on all platforms except Darwin: /...

...-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > We were just debugging a sporadic crash the other day, when we noticed > that RIP-relative addressing was being used in a JumpTable, even when > code and data were well over 4G apart. This is confusing, because we > picked CodeModel::Large, and expected this to be taken care of. Isn't > that what gcc would do given a Large CodeModel? > This sounds like a bug, but I can't reproduce it. Testcase? > The default Relocation Model, Reloc::Default, folds into Reloc::PIC_ > in most cases. However, if we explici...

...> <llvm-dev at lists.llvm.org> wrote: >> We were just debugging a sporadic crash the other day, when we noticed >> that RIP-relative addressing was being used in a JumpTable, even when >> code and data were well over 4G apart. This is confusing, because we >> picked CodeModel::Large, and expected this to be taken care of. Isn't >> that what gcc would do given a Large CodeModel? > > > This sounds like a bug, but I can't reproduce it. Testcase? I've attached an example with a standard switch instruction, compiled with `llc -code-model=large`....

...lists.llvm.org> wrote: > >> We were just debugging a sporadic crash the other day, when we noticed > >> that RIP-relative addressing was being used in a JumpTable, even when > >> code and data were well over 4G apart. This is confusing, because we > >> picked CodeModel::Large, and expected this to be taken care of. Isn't > >> that what gcc would do given a Large CodeModel? > > > > > > This sounds like a bug, but I can't reproduce it. Testcase? > > I've attached an example with a standard switch instruction, compiled &...

...rnal to the mach-o ArchHandler. Given that, using a Reference Kind to track thumbness (which only ArchHander_arm cares about), works well. That said, the ability to handle thumb and arm within a function is probably over engineering. I’d be fine with adding to DefinedAtom something like: enum CodeModel { // Note: all these values need word smithing codeNA, codeMIPS_PIC, codeMIPS_micro, codeMIPS_16, codeARM_16, codeARM_32, }; virtual CodeModel codeModel() { return codeNA; } -Nick > > On Tue, Nov 11, 2014 at 11:19 AM, Nick Kledzik <kledzik at apple.com&g...

...tMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options, Optional<Reloc::Model> RM, Optional<CodeModel::Model> CM, CodeGenOpt::Level OL, bool JIT) : LLVMTargetMachine(T, computeDataLayout(TT), TT, CPU, FS, Options, getEffectiveRelocModel(RM), getEffectiveCodeModel(CM), OL), TLOF(make_unique<TargetLower...

Martin, Thanks for your suggestion. I look at these tests, try to make them work for COFF. Adam On 2019. 10. 02. 12:23, Martin Storsjö wrote: > On Wed, 2 Oct 2019, Adam Kallai wrote: > >> I'm working Chromium targeting Windows on ARM64 platform. As a part >> of this work I ran into an issue related to llvm in Swiftshader. >> >> Currently fixup_aarch64_movw

Hi Elena, > (2) Proposal > Define one more Code Model, let's say "LargeNearConst", which will allow to put constants in .text. Isn't that a little heavy-handed? The large model only requires the less efficient access for symbols we can't control, and in fact x86 still uses pc-relative conditional branches within a function so it can't pretend to support a single

...   generic_ptr_ = llvm::PointerType::get( llvm::Type::getInt8Ty(context), 0 );     f_natural_int = llvm::IntegerType::get(context, 64);     module->getOrInsertFunction(         "count_malloc", generic_ptr, f_natural_int, (llvm::Type*)0 ); It appears there is no more Reloc::Default or CodeModel::Default, but the docs on those fields indicate there is still a target default. How do I get the default relocation and codeModel? I'm still using the legacy::PassManager. Is there a new way to do the passes now? There docs still reference `tool_output_file*`*, but it appears the new name, i...

...read-only section, and this section may be far from the text section. I'm working with JIT model or with only one object file. The code model, when all constants are near, we can call "LargeJIT". (Is it sounds better then LargeNearConst?) For X86 target JITDefault will be translated CodeModel::LargeJIT for x64 and CodeModel::Small for 32-bit. And the TargetLoweringObjectFile already has CodeModel inside. So the code will look like : const MCSection * TargetLoweringObjectFile::getSectionForConstant(SectionKind Kind) const { if (getCodeModel() == CodeModel::LargeJIT) return TextSe...

Hi all, I analyzed more and ready (1) to describe the problem and (2) I have a proposal. (1) Problem description: In X86_64 target the Code Model is "Large". It means that address is 64-bit and IP-relative memory operand can't be used in this case. (Because in IP-relative memory operand the displacement is 32-bit). In order to load constant, we use 2 instructions. movabsq

On Thu, 2013-01-31 at 11:29 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > > ----- Original Message ----- > > > > > From: "Bill Schmidt" <wschmidt at

...o fix the > large code model on amd64, but this affects JITs which can guarantee that > both the caller and callee have 32 bit addresses, since the code model is > set uncoditionally to Large, even if another code model was passed to > createJIT (): JIT::createJIT() intends to obey the CodeModel you pass it, but someone else was complaining of a bug there too. The CodeModel is definitely intended to be configurable, specifically so that users can specify the guarantees their JITMemoryManager provides. Still, it's supposed to be an optimization. The large code model should always produc...

Hi, Recently I hit an issue that LLJIT crashes when CodeGenOpt::Less or higher is given. After investigation, it turned out that the issue is some global constant string in the IR, like > @.str.117 = private unnamed_addr constant [9 x i8] c"lineitem\00", align 1 > becomes an invalid pointer in the generated code. > $1 = 0xf7fab054 <error: Cannot access memory at address

...tiveBlockAddress(MO.getMBB()); } else if (MO.isGlobalAddress()) { - bool NeedStub = !IsStatic || + bool NeedStub = Opcode == X86::TAILJMPd || Opcode == X86::TAILJMPr || + Opcode == X86::TAILJMPm || !IsStatic || (Is64BitMode && TM.getCodeModel() == CodeModel::Large); emitGlobalAddress(MO.getGlobal(), X86::reloc_pcrel_word, 0, 0, NeedStub);

...and only parts of the LLVM JIT infrastructure, we would prefer patching the calling code instead of patching the stub, to avoid the overhead of going through the stub at every call, also our JIT expects to be able to patch the call sites. > someone else was complaining of a bug there too. The CodeModel is > definitely intended to be configurable, specifically so that users can > specify the guarantees their JITMemoryManager provides. Still, it's > supposed to be an optimization. The large code model should always > produce correct code. > > It does produce current code, its...

Currently it appears X86WrapperRIP is only implemented in the small code model, which causes code to fail to select in other code models. My particular use case is MCJIT, where the default code model is large (the X86WrapperRIP comes from a TLS variable reference). What would be the best way to implement this? I'd be happy to take a crack at it myself, but I really don't know my way around

...I tried to play with TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule); builder.setOptLevel(CodeGenOpt::Aggressive); builder.setEngineKind(EngineKind::JIT); builder.setUseMCJIT(true); builder.setCodeModel(CodeModel::JITDefault); builder.setMCPU(llvm::sys::getHostCPUName()); TargetOptions targetOptions; targetOptions.NoFramePointerElim = true; targetOptions.LessPreciseFPMADOption = true; targetOptions.UnsafeFPMath = true; targetOptions.NoInfsFPMath = true; targetOptio...

I'm trying to add static code generation capabilities to my MCJIT compiler on LLVM 3.4. To that extent I have: targetMachine = engineBuilder.selectTarget(); // ... targetMachine->addPassesToEmitFile(<...>); At first glance this appears to work, but when linking the object file I get the warning: ld: warning: PIE disabled. Absolute addressing (perhaps

On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > ----- Original Message ----- > > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > > To: llvmdev at cs.uiuc.edu > > > > Sent: