similar to: llvm-dev Digest, Vol 150, Issue 37

----- Original Message ----- > From: "Reid Kleckner via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 8, 2016 7:05:44 PM > Subject: [llvm-dev] RFC: Adding argument allocas > Clang is currently missing some low-hanging performance and code size > opportunities when receiving

On Fri, Dec 9, 2016 at 10:30 AM, Friedman, Eli <efriedma at codeaurora.org> wrote: > Mmm... maybe. The part I really don't like is the implied store: there > are a lot of transformations which specifically reason about store > instructions, and they would all need to be fixed to specifically deal with > "alloca with an argument" so it doesn't block

On Fri, Dec 9, 2016 at 1:30 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 12/9/2016 8:45 AM, Reid Kleckner wrote: > > On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> So IIUC basically the *only* reason for this IR change is that we don’t >> want to pattern match in debug build? >> I don't

This sounds right to me. If there is no objection, I will implement a patch to enforce this in langref and IR verifier. -----Original Message----- From: Friedman, Eli [mailto:efriedma at codeaurora.org] Sent: Tuesday, September 25, 2018 3:07 PM To: Pan, Wei <wei.pan at intel.com>; Reid Kleckner <rnk at google.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re:

On Thu, 20 Sep 2012 10:18:46 -0700 Chris Lattner <clattner at apple.com> wrote: > On Sep 18, 2012, at 3:11 AM, Richard Osborne <richard at xmos.com> wrote: > >>> I want it to be configurable. On my target there is no advantage > >>> to aligning anything by more than a 4 bytes - it just wastes > >>> space. I'll try to put together a proposal

To recap, it seems like there are two people so far opposed to this proposal, and tentative support from a number of others. It's not clear to me if I should go ahead with this. I'll try to bug some more people to get more input here. In the meantime, I think I'll implement the simple pattern matching, since that can be done incrementally, and can be simplified afterwards by the IR

Clang is currently missing some low-hanging performance and code size opportunities when receiving function parameters. For most scalar parameters, Clang typically emits an alloca and stores the LLVM SSA argument value into the alloca to initialize it. With optimizations, this initialization is often removed, but it stays behind in debug builds and when the user takes the address of a parameter (

On Mon, Mar 9, 2015 at 12:38 PM, Reid Kleckner <rnk at google.com> wrote: > If we're keeping types on GEP, > You mean rather than just dropping gep entirely & doing manual pointer arithmetic? (& moving inbounds 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

On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > So IIUC basically the *only* reason for this IR change is that we don’t > want to pattern match in debug build? > I don't understand right now why we wouldn’t want to do this? > If we need to pattern match such a basic construct, it suggests to me that we have the wrong representation, and we

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

Hi Reid, On 25/07/13 23:38, Reid Kleckner wrote: > Hi LLVM folks, > > To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able > to take the address of an outgoing call argument slot. This is > http://llvm.org/PR5064 . > > Problem > ------- > > On Windows, C structs are pushed right onto the stack in line with the other > arguments. In

It is problematic when byval argument is not from address space 0. When the default alloca address space is 0, should we consider this IR illegal? define internal i32 @bar(i32 addrspace(1)* byval %a) alwaysinline From: Reid Kleckner [mailto:rnk at google.com] Sent: Tuesday, September 25, 2018 2:38 PM To: Pan, Wei <wei.pan at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>

On Fri, Dec 9, 2016 at 4:04 PM, James Y Knight <jyknight at google.com> wrote: > IMO, the LLVM function definitions should be a straightforward > transformation from the C function signatures, and clang should stop > mangling the function signatures with its own intimate knowledge of the > calling convention rules. > > Instead, clang could emit (still ABI-specific!)

On Sat, Dec 10, 2016 at 8:20 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Having an alloca with an initializer seems like a reasonable enhancement. > Please, however, without all of these special restrictions: any value > should be accepted on any alloca. We can match the special argument cases > in the backend and otherwise lower to the equivalent of an alloca+store. > We

How do you handle this during codegen? One problem is avoid stack changes (like spills). Another is coordinating things that are using allocas and those that are not but end up in the stack. Consider void foo(int arg1, int arg2, int arg3, ....CXXTypeWithCopyConstructor argn, int argp1...) You will need an alloca for argn, but the ABI also requires it to be next to the plain integers that

Great, thank you! On Wed, Aug 31, 2016 at 2:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ------------------------------ > > *From: *"Chris Sakalis" <chrissakalis at gmail.com> > *To: *"Daniel Berlin" <dberlin at dberlin.org> > *Cc: *"Hal Finkel" <hfinkel at anl.gov>, "David Majnemer" < > david.majnemer

Moving this to llvm-dev where I should've sent it in the first place (& +Chandler, because we discussed this offline a bit) On Thu, Feb 19, 2015 at 11:32 AM, Reid Kleckner <rnk at google.com> wrote: > On 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 <

> I suspect #2 is the right design, mostly because I suspect most of the interesting and important inference cases are going to be cases where we can easily infer the stronger guarantee, and once inferred we will have much more freedom to optimize based on this stronger guarantee... Can't the stronger guarantee be represented in the existing system by either: * Adding 'readonly'

On 5 November 2014 12:48, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Nick Lewycky" <nlewycky at google.com> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Reid Kleckner" <rnk at google.com>, "LLVM Developers Mailing List" < > llvmdev at cs.uiuc.edu> > >

On Sep 18, 2012, at 3:11 AM, Richard Osborne <richard at xmos.com> wrote: >>> I want it to be configurable. On my target there is no advantage to aligning anything by more than a 4 bytes - it just wastes space. I'll try to put together a proposal for making it possible to set this per target. >> Ok, after considering this a bit more, how about we take a different approach: