similar to: [LLVMdev] Patch proposal: ARM MC relocations

Sorry, I have been very behind on patch reviews. Bob and Jim, do you have any opinions about this? Evan On Jun 2, 2010, at 5:18 AM, Renato Golin wrote: > Hi, > > Is there any interest in this patch? Is there any better way of doing this (that will be accepted mainstream)? > > I noticed my cast check was wrong (LLVM cast asserts, rather than return a null pointer). Also,

Is there a way to handle this entirely in the ARM AsmPrinter bits? Adding pieces to the generic MC stuff feels a bit like overkill at first impression. On a minor note: You probably want dyn_cast<> instead of cast<> so you can do something like: if (const MCSectionELF* SectionELF = dyn_cast<MCSectionELF>(Section)) { // ... } -Jim On Jun 16, 2010, at 3:44 PM, Evan Cheng

Hi, I'd like to add support for addrspacecast in initializers of global variables, at least for the trivial case. The trivial case is if TargetLowering::isNoopAddrSpaceCast(SrcAS, DestAS) returns true. In this case the MCExpr for the addrspacecast is the MCExpr of its first operand. It seems hard to obtain an instance of TargetLowering in AsmPrinter::lowerConstant(). Other methods in

On Fri, Oct 7, 2016 at 1:55 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote: > On Fri, Oct 7, 2016 at 1:22 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Fri, Oct 7, 2016 at 12:20 PM, Evgenii Stepanov > > <eugeni.stepanov at gmail.com> wrote: > >> > >> I've tried implementing some of the alternatives mentioned in

On Fri, Oct 7, 2016 at 2:48 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote: > On Fri, Oct 7, 2016 at 2:28 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Fri, Oct 7, 2016 at 1:55 PM, Evgenii Stepanov < > eugeni.stepanov at gmail.com> > > wrote: > >> > >> On Fri, Oct 7, 2016 at 1:22 PM, Peter Collingbourne <peter

Hi Allan, Thanks for the fix! So is this a bug in LLVM? Can you reduce that to a small test case and file a bug? Nicolas 2010/8/2 Allan Tong <actong88 at gmail.com> > On Mon, Jul 19, 2010 at 7:40 PM, Minas Abrahamyan <minas.subs at gmail.com> > wrote: > > Trying to build AOT version of vmkit java, > > building for that classpath glibj.zip: > > > > $ cd

Hello, Renato > While Clang doesn’t include the TARGET2 relocation information, and that > mess up cross-linking. Is there any documentation for this stuff? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Fri, Oct 7, 2016 at 12:20 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com > wrote: > I've tried implementing some of the alternatives mentioned in this > thread, and so far I like this syntax the most: > > i32 reloc (29, void ()* @f, 3925868544) > ; 29 = 0x1d = R_ARM_JUMP24 > ; 3925868544 = 0xea000000 > > Note the zeroes in the relocated data instead of

On Mon, Jul 19, 2010 at 7:40 PM, Minas Abrahamyan <minas.subs at gmail.com> wrote: > Trying to build AOT version of vmkit java, > building for that classpath glibj.zip: > > $ cd vmkit/tools/vmjc/libvmjc > $ make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1 REQUIRES_FRAME_POINTER=1 > > has eventually, after 50 minutes, brought: > <<< > llvm[0]: Compiling

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

On 17 June 2010 00:06, Jim Grosbach <grosbach at apple.com> wrote: > Is there a way to handle this entirely in the ARM AsmPrinter bits? Adding > pieces to the generic MC stuff feels a bit like overkill at first > impression. Hi Jim and Evan, At first, I thought I could do that, but it is MCAsmStreamer that is printing the final value of most symbols together with their EOL. So,

Hi, Trying to build AOT version of vmkit java, building for that classpath glibj.zip: $ cd vmkit/tools/vmjc/libvmjc $ make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1 REQUIRES_FRAME_POINTER=1 has eventually, after 50 minutes, brought: <<< llvm[0]: Compiling glibj.zip to llvm llvm[0]: Optimizing glibj.zip llvm[0]: Compiling glibj.zip.bc to native UNREACHABLE executed! 0 llc

Well, I think there is a bug in vmkit for always trying to do pointer arithmetic using i32 instead of the target's pointer size, which is what my patch addressed. As for whether there is a bug in LLVM, I'm not sure. I've played around with it some more, and it looks like zext expressions get constant folded before reaching LowerConstant. The only way I've triggered the

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

Jim, Both the branch and the branch target are in the same function. This is known delta and should not matter where it is relocated because the delta will remain the same once it is a .o or later. I just want to know how to tell the compiler that this expression is target offset - branch offset. More generally, I want to know the rules for setting up expressions in general. I have no idea if

Gang, I'm tasked with direct object generation for Mips and am trying to not hack the code. I how exactly does one set an expression to be PC relative and if the compiler can resolve it, not produce a relocation? In our case, the backend produces an expression for the branch which is the target label. I make a call from the .td for the branch instruction which calls a routine in

Hi, I was wondering how exactly LLVM handles the ConstantExpr, specifically GEP ConstantExpr, in code generation. From what I'm reading, translating these Constant Expressions into Instructions can slow the code, so I'd like to be able to handle ConstantExpr in the same way that LLVM code generation does. Thanks, Brandon

On Oct 10, 2011, at 10:11 AM, Jack Carter wrote: > Gang, > > I'm tasked with direct object generation for Mips and am trying to not > hack the code. > > I how exactly does one set an expression to be PC relative and if the > compiler can resolve it, not produce a relocation? > Fixups are created for all expressions that may need a relocation. The MC layer evaluates

Hi everyone, happy new year. This note is to announce that support for PC relative reloc tags for movw/movt is nearing completion (hopefully <48hrs!). This work is is from Jan Voung, David Meyer and myself. Unfortunately, to test this change, we need to patch ARM/AsmParser to address http://llvm.org/bugs/show_bug.cgi?id=8721 Locally, we have hacked up a solution to 8721, but its not ideal

Really sorry I missed this. Just found it looking for something else in my inbox. I think we should support this but * We should still err on other identifiers ".cfi_startport bar" is invalid. * If I read the gas documentation correctly, the effect of "simple" is to skip the initial cfi instructions. We should test if that is the case and implement it too. Accepting and