similar to: [LLVMdev] making trampolines more portable

Eli Friedman wrote: > Also, for lack of an intrinsic, there's a relatively easy workaround: > you can declare a global containing the correct size, then link in a > small target-specific .bc with the definition right before code > generation. So why can't LLVM provide that global? I don't care whether it's a global, intrinsic, or whatever. If I have to provide

Duncan Sands wrote: > is it important for you to have portable bitcode (i.e. the trampoline > size as some kind of symbolic constant, maybe via a global or an > intrinsic) that works on all targets or would it be enough to have the > LLVM info for the target expose the trampoline size, so when generating > IR for a target X you would query the method for target X and if it

Eli Friedman wrote: > I didn't say we wouldn't accept a patch. It's just that up until now > nobody has particularly cared because trampolines aren't used very > much. Fair enough. If I get to the point where I understand how to implement it cleanly, I'll submit a patch. Best regards, Eric

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was

Hi Sanjoy, the first and last patches look good (except that you didn't add any tests for the auto-upgrade functionality). Comments on the other two below. > Attached patches split init.trampoline into adjust.trampoline and > init.trampoline, like in gcc. > > As mentioned in the previous mail, I've not made a documentation > patch, since I'm not sure about what the

Chris Lattner wrote: > On Mon, 31 Mar 2008, Jon Sargeant wrote: >> I'm attaching another round of changes. Please verify that they are correct. > > Applied with edits: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html > > I figured out what your patches don't apply. Something (your web browser, > editor, etc) is stripping

Hi, My recent refactoring of the (machine-dependent) use of <alloca.h> does not attempt to change CWriter's behavior of emitting a #include for <alloca.h>. FreeBSD does not have <alloca.h>, so this would cause trouble. We could change it to emit an #ifndef __FreeBSD__...#endif around #include <alloca.h>. I suggest this because, I'm guessing, whether or not the

On Mon, 2003-06-16 at 17:33, John Criswell wrote: > What would be better yet is to modify the code so that it does not use > alloca() at all. There seems to be little reason to use it aside from > convenience (but perhaps I have missed something). I think the idea is that alloca can give (probably significant) performance gains when used properly. In the cases where you need

On Thu, Feb 17, 2011 at 1:07 PM, Talin <viridia at gmail.com> wrote: > On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > >> I think I'm one of the few people actually using LLVM's support for >> garbage collection, and so far I've found it very difficult to generate code >> that uses llvm.gcroot() correctly. >> >> In

The IR update to allow vector types was here: https://reviews.llvm.org/D57090 ...we didn't update the docs at that time because it was not clear what the backend would do with that, but that might've changed with some of the more recent patches. On Sat, Feb 9, 2019 at 1:42 AM Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don't think I understand your

Jon Sargeant wrote: > Chris Lattner wrote: >> On Mon, 31 Mar 2008, Jon Sargeant wrote: >>> I'm attaching another round of changes. Please verify that they are correct. >> Applied with edits: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html >> >> I figured out what your patches don't apply. Something (your web

I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {

The pointers must always be i8* the alignment is independent and is controlled by the attributes on the arguments in the call to memcpy. ~Craig On Mon, Jan 29, 2018 at 11:45 PM, ma jun <jun.parser at gmail.com> wrote: > Hi > > > 2018-01-30 15:36 GMT+08:00 ma jun <jun.parser at gmail.com>: > >> Hi >> Thanks ! >> so for this example >>

I'm interested in using @llvm.experimental.vector.reduce.smax/umax to implement runtime overflow checking for vectors. Here's an example checked addition, without vectors, and then I'll follow the example with what I would do for checked addition with vectors. Frontend code (zig): export fn entry() void { var a: i32 = 1; var b: i32 = 2; var x = a + b; } LLVM IR code:

Hi, 1. Does the alignment of the pointer returned by an AllocaInst depend on the instructions before it in the basic block? The 1st snippet below aligns 'a' correctly, while the 2nd one doesnt. (the method handle_args, only prints out the values of arguments, and returns argv unchanged). define i32 @main(i32 %argc, i8** %argv) nounwind { entry: %argc_addr = alloca i32

On Mon, Jul 11, 2016 at 2:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > ping! > > Sanjoy Das wrote: > # Proposed Solution: >> >> We introduce a "new" LLVM type. I will still refer to it as GCREF >> here, but it may actually still be "<ty> addrspace(k)*" where k is >> specially noted in the datalayout. >>

Dale Johannesen wrote: > On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > >> If <NumElements> is zero, what is the behavior of malloc() and >> alloca()? >> Can I call free() using the pointer that malloc() returns? > > alloca is not standard. > The behavior of malloc is covered in 7.20.3p1: > > If the size of the space requested is zero, the

Hi Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a

On Sep 13, 2008, at 1:07 PM, Matthijs Kooijman wrote: > Hi Dan, > >> Changing PromoteCastOfAllocation to not replace aggregate allocas >> with >> non-aggregate allocas if they have GEP users sounds reasonable to me. > This sounds reasonable indeed, but still a bit arbitrary. Haven't > figured out > anything better yet, though. > >> Finding the

On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > I think I'm one of the few people actually using LLVM's support for garbage > collection, and so far I've found it very difficult to generate code that > uses llvm.gcroot() correctly. > > In the current scheme, it is the frontend's responsibility to insure that > any intermediate SSA