search for: inalloca

Hello all, A few years ago, I added the inalloca feature to LLVM IR so that Clang could be C++ ABI compatible with MSVC on 32-bit x86. The feature works, but there is room for improvement. I recently took the time to write up a design using token values that will hopefully be better named and easier to work with and around. For the technical det...

I wanted to mention that I'm planning to start writing and sending out patches for this. Naming the attribute 'alloca' was really confusing, so I'd like to change it to 'inalloca', which follows the preposition pattern of inreg and byval. After discussion, we decided it was silly to add stackbase uses to alloca instructions. They should stay simple. Instead, we'll clarify that it is illegal for an optimization to raise an alloca used as an inalloca argument acros...

Bringing this back up for discussion on handling exceptions. According to the inalloca design <https://llvm.org/docs/InAlloca.html>, there should be a stackrestore after an invoke in both the non-exceptional and exceptional case (that doesn't seem to be happening in some cases as we've seen, but that's beside the point). Does it make sense to model a preallocated c...

...unds to an attribute on pointer addition, I guess?) > then IMO we should keep them on allocas and globals. It keeps the IR human > readable. > & what of byval, then? Do you agree with Chandler's argument from analogy between byval, alloca, and globals? (oh, and I should look at inalloca a bit too - it looks like it uses the getByValTypeAlignment too... ) - David > > We're pretty close to mandatory data layout, so computing the size and > alignment of these things when they aren't explicitly specified should be > easy. > > On Mon, Mar 9, 2015 at 9:57 AM...

...nt to make the > calls “noduplicate”, it isn’t that terrible of an alternative. > Does "noduplicate" block inlining, though? Maybe we really want "convergent"? In any case, I'm OK with powering down jump threading to pick up IPO, which is incompatible with today's inalloca. > Good. It might be a good idea to try to write out an algorithm for this > to ensure this works out. In particular, I’m concerned about cases where > two predecessors of a basic block appear to have a different stack size (an > if-then-else, or a loop backedge). We need to make s...

Hi, In the past months, several options have been presented for making byval (and similar attributes, such as inalloca or sret) work with opaque pointers. The main two I've seen were byval(T) and byval(N) where N is the size of T. They both have their upsides and downsides, for example: byval(T) would be a type-parametric attribute, which, AFAIK, does not already exist and may complicate the attribute system...

...you're suggesting for now. Perhaps revisit the question when things start getting tricky. > Is byval already fixed/changed? I may've lost track of some of these changes, but I knew that was next on my list. (& how was byval addressed - byval(<ty>) or byval(byte count)? I guess inalloca goes/should go the same way as byval) byval(<ty>) is in, and used by Clang now. In retrospect I should have done inalloca at the same time, but for some reason I decided it wasn't necessary. I think it'll need the same conversion, and then both must be made compulsory. Cheers. Tim.

...I don't think I could do it completely alone because some choices will need input from experts. Even if I could, it would finish with a patch bomb even bigger than what I'm dropping here. Proposal ======== Short term (because otherwise we can't do it for another six months): 1. Add inalloca(<ty>) support. 2. Document for January release the planned removal of: * Old style byval * Old style inalloca * Typeless CreateCall, CreateLoad, CreateGEP. 3. Soon after January branch, strip out those bits. The third in particular should prevent front-end regression, I had to fix a fai...

...rts > further down the trail). > > On Tue, Jan 19, 2016 at 2:47 PM, Eddy B. via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> In the past months, several options have been presented for making byval >> (and similar attributes, such as inalloca or sret) work with opaque >> pointers. >> >> The main two I've seen were byval(T) and byval(N) where N is the size of >> T. >> >> They both have their upsides and downsides, for example: byval(T) would be >> a type-parametric attribute, which, AFAIK, do...

...uot;. Two prototypes are congruent if all return and parameter types match except for the pointer types. The pointer types can have different pointee types, but they must have the same address space. In addition, all the ABI impacting attributes on the parameters must be the same, meaning byval, inalloca, inreg, etc, must all match up. Second, the call must be in tail position. The call must be immediately followed by a bitcast or a ret, both of which must use the result of the call. If there is a bitcast, it must be followed by a ret which uses the bitcast. Importantly, LLVM must perform TCO r...

On Mon, Jan 27, 2020 at 4:31 PM Eli Friedman <efriedma at quicinc.com> wrote: > I assume by “drop support”, you mean reject it in the bitcode reader/IR > parser? We can’t reasonably support a complex feature like inalloca if > nobody is testing it. If we can’t reasonably upgrade it, and we don’t think > there are any users other than clang targeting 32-bit Windows, probably > dropping support is best. > That's a good point. There are already enough lightly tested features in LLVM. There's no rea...

Sorry for the delay. Arthur Eubanks has started working on the design here: https://reviews.llvm.org/D74651 I felt I should follow up here about that. On Mon, Jan 27, 2020 at 6:47 PM Eli Friedman <efriedma at quicinc.com> wrote: > It doesn’t seem like multiple call sites should be a problem if they’re > sufficiently similar? If the argument layout for each callsite is the > same,

Hi sorta piggybacking on the other thread. I am looking for some feedback on how to implement the following idea in llvm. The really short version of the idea is this: * I want to alloca a field (record/struct), so that its size is an even multiple of 64 bytes. [^1] * This allocaed field will be exclusively used as an argument to functions * llvm should be aware of the extra bytes and should

Hello LLVM Developers, I am curious if it is possible to get the actual address in memory of where the parameter or return memory location is on to the stack prior to the call or return being made in the LLVM IR. If these things are possible how is it done in a safe manner? Thanks, Carter. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Currently, the alloca instruction always allocates in the generic address space (0). This proposal is to extend the semantics of alloca instruction to allow allocation in any specified address space. Proposed Syntax <result> = alloca [inalloca] <type> [, <ty> <NumElements>] [, align <alignment>] [, addrspace <num>] ; yields type addrspace(num)*:result Motivation Managed language clients typically use address space 1 to represent GC-pointers. Some managed clients (CLR, in particular) allow construction of GC...

...Thu, Feb 19, 2015 at 10:57 AM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola < >> rafael.espindola at gmail.com> wrote: >> >>> Long term I would love to remove byval and sret. With inalloca the >>> outgoing frame is explicit a the IR and we just have loads and stores. >>> >>> A short term idea would be to add just the size to the byval. That >>> should be sufficient, no? >> >> > I like this idea! > So do I. Chandler had some othe...

...writing both formats) while using only a narrow whitelist of places that request the type of a pointer (things like the verifier, the parser/printer where it actually needs the typed pointer to verify it matches the explicit type, etc). The next thing on the list is probably figuring out the byval/inalloca representation (add an explicit pointee type? just make the number of bytes explicit with no type information?). Then start migrating optimizations over - doing the same sort of testing I did for the IR/bitcode roundtripping - assert that the pointee type is not accessed, whitelist places that nee...

...ile using only a narrow > whitelist of places that request the type of a pointer (things like the > verifier, the parser/printer where it actually needs the typed pointer to > verify it matches the explicit type, etc). > > The next thing on the list is probably figuring out the byval/inalloca > representation (add an explicit pointee type? just make the number of bytes > explicit with no type information?). > > Then start migrating optimizations over - doing the same sort of testing I > did for the IR/bitcode roundtripping - assert that the pointee type is not > access...

...th formats) while using only a narrow whitelist of places that request the type of a pointer (things like the verifier, the parser/printer where it actually needs the typed pointer to verify it matches the explicit type, etc). > > The next thing on the list is probably figuring out the byval/inalloca representation (add an explicit pointee type? just make the number of bytes explicit with no type information?). > > Then start migrating optimizations over - doing the same sort of testing I did for the IR/bitcode roundtripping - assert that the pointee type is not accessed, whitelist place...

...n because the type information didn't end up aligning to produce the optimal output. & I know I've been off the typeless pointer stuff for a few months working on llvm-dwp - but happy for any help (the next immediate piece is probably figuring out teh right representation for byval and inalloca - there were some code reviews sent out for that that I'll need to come back around to - but also any optimizations people want to help rework/improve would be great too & I can provide some techniques/tools to help people approach those) - Dave > > Thanks, > > -- > Mehdi...