search for: debugbuilder

Hi, I am trying to generate LLVM code that calls a "native" function in the parent program (the program hosting the JIT). I think that I have figured out how to do this, but I get the following assertion failure when the LLVM code is executed: ../llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23)

...f() and alignmentof() first-class operations in the IR would have the advantage of making the generated IR clearer; And we already know that it can be done because the tricks exist. A lot of this thinking comes out of my attempting to create (as I mentioned on the other thread) a generic "DebugBuilder", similar to IRBuilder, that pumps out source level debugging definitions. As much as possible, I want to hide details of the target machine from the user of the API. You ought to be able to hand it an LLVM type, plus a little sprinkling of source-derived metadata to go along with it, and...

Hi folks, I'm hitting the below assertion failure when compiling this small piece of C code (repro.c, attached). My command line is: bin/clang --target=aarch64-linux-gnu -c -O2 repro.c clang is built from top of trunk as of this morning. It only happens at -O2, and it doesn't happen with the default target (x86_64). I tried to reproduce using just 'llc -O2' but didn't

Thanks for notifying me. Yes, this was a recent change. Taking a look now. On Wed, Jul 20, 2016 at 1:49 PM, Michael Kuperstein <mkuper at google.com> wrote: > +Sanjay, who touched this last. :-) > > On Wed, Jul 20, 2016 at 12:44 PM, Ismail Badawi (ibadawi) via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi folks, >> >> I'm hitting the

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

Sure. David, what do you think about merging this to 3.9? Sanjay: are you saying I'd just apply that diff to InstructionSimplify.cpp, not InstCombineSelect.cpp? On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: > Hi Hans - > > Yes, I think this is a good patch for 3.9 (cc'ing David Majnemer as code > owner). The functional change was

On May 22, 2008, at 6:40 PM, Talin wrote: >> LLVM already does this. >> >> http://www.nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt >> >> — Gordon >> > Is there a similar technique that would allow calculation of the > alignment? (which is also required by the DWARF derived-type > descriptor.) There is more than one form of

Gordon Henriksen wrote: > On 2008-05-21, at 22:17, Talin wrote: > >> As I understand this, this issue and others like it all require a >> difficult step to be taken, which is to introduce the concept of a >> constant whose value is not known until code generation time or at >> least >> until the compilation target is fully known. These "late bound

David, Sanjay: ping? On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org> wrote: > Sure. David, what do you think about merging this to 3.9? > > Sanjay: are you saying I'd just apply that diff to > InstructionSimplify.cpp, not InstCombineSelect.cpp? > > On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: >> Hi

LGTM On Wednesday, July 27, 2016, Hans Wennborg <hans at chromium.org> wrote: > David, Sanjay: ping? > > On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org > <javascript:;>> wrote: > > Sure. David, what do you think about merging this to 3.9? > > > > Sanjay: are you saying I'd just apply that diff to > >

Hi, This is a follow up to my previous email since I have now found out a bit more about what goes wrong. I am generating JIT code that calls a native function, but I get the following assertion telling me that the PC relative jump is too long: /llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) &&

...purely as a symbolic, opaque object, while the code generator simply converts it into a ConstantInt. This makes filling in the dwarf debugging structures relatively easy as long as you have an LLVM type reference to use as a measuring stick. In fact, I'd likely make the hypothetical "DebugBuilder" API such that most of the info was derived from an LLVM type given as a parameter, with just a few additional parameters to specify the things that cannot be determined just from looking at the the LLVM type. -- Talin

On Wed, 21 May 2008, Talin wrote: > On a related topic: The source-level debugging descriptors require you > to know up front what the sizeof pointer types are. Is there any hope of > the frontend remaining blissfully unaware of platform details? I really don't know how to do this. The current debug info stuff depends on emitting size info into the IR. At this point, I don't

On a related topic: The source-level debugging descriptors require you to know up front what the sizeof pointer types are. Is there any hope of the frontend remaining blissfully unaware of platform details? Chris Lattner wrote: > On May 6, 2008, at 11:12 PM, Talin wrote: > > >> For the most part, it appears that writing a front end can be almost >> entirely