[llvm-dev] llvm-dev Digest, Vol 150, Issue 37
hameeza ahmed via llvm-dev
llvm-dev at lists.llvm.org
Sat Dec 10 12:13:09 PST 2016
Thank you vivek pandya.
I will try my best to do things as you mentioned.
Regards
Hameeza Ahmed
On Sun, Dec 11, 2016 at 1:00 AM, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> Send llvm-dev mailing list submissions to
> llvm-dev at lists.llvm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> or, via email, send a message with subject or body 'help' to
> llvm-dev-request at lists.llvm.org
>
> You can reach the person managing the list at
> llvm-dev-owner at lists.llvm.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of llvm-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: LLVM possible projects (vivek pandya via llvm-dev)
> 2. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev)
> 3. Re: [cfe-dev] 3.9.1-rc3 has been tagged
> (Renato Golin via llvm-dev)
> 4. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev)
> 5. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev)
> 6. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev)
> 7. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 10 Dec 2016 13:50:38 +0530
> From: vivek pandya via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev <llvm-dev at lists.llvm.org>,
> llvm-dev-request at lists.llvm.org
> Subject: Re: [llvm-dev] LLVM possible projects
> Message-ID:
> <CAHYgpo+9R7pJuMGRgtQBbMahHPa=UmU1sZ4eR-DkTNCKcDyyKg at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> > Hello,
> > Presently my research is focused on compiler and i found LLVM great tool
> to
> > work with. I want to familiarize it at undergraduate level.
> >
> > Hi Hameeza,
>
> I have face similar situation before and I would suggest you to read some
> books/ blogs available on Internet for LLVM.
> I think the best way to understand LLVM is by playing with it.
> Then you should try doing some assignments based on LLVM from some good
> universities.
> For example :
> https://utah.instructure.com/courses/377698/assignments/3299816
>
> or
> https://www.cs.cmu.edu/afs/cs/academic/class/15745-s09/www/
> assignments/1/P1.pdf
>
> or https://wiki.aalto.fi/display/t1065450/assignments+2015
>
> almost all good universities have LLVM based course structure for Advance
> compiler courses
>
> Could you suggest some good optimization and backend based LLVM projects at
> > undergraduate level.
> >
> > Once you get enough experience then you can contact some community member
> on IRC asking some task which is yet to be done but because of busy
> schedule LLVM-Dev are not able to work on it.
>
> Also as you are student I will encourage you to participate in Google
> Summer of Code 2017.
>
> Hope this helps!
>
> - Vivek
>
> > Thankyou
> >
> > Regards
> > Hameeza Ahmed
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20161210/bb0f1ca8/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 10 Dec 2016 09:01:38 -0600
> From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org>
> To: James Y Knight <jyknight at google.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] RFC: Adding argument allocas
> Message-ID:
> <593911.506.1481382095370.JavaMail.hfinkel at sapling5.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> ----- Original Message -----
>
> > From: "James Y Knight via llvm-dev" <llvm-dev at lists.llvm.org>
> > To: "Eli Friedman" <efriedma at codeaurora.org>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> > Sent: Friday, December 9, 2016 6:04:18 PM
> > Subject: Re: [llvm-dev] RFC: Adding argument allocas
>
> > 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 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 should instead make
> > > > our representation more accurately model reality. To me, it feels
> > > > like this representation allows several good things to just "fall
> > > > out" without any additional work, and that suggests it's a good
> > > > representation.
> > >
> >
> > > 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
> > > optimizations. Every feature we add to the IR makes it more
> > > difficult to write IR transformations, and this really doesn't seem
> > > to carry its own weight.
> >
>
> > > A couple of other thoughts I had:
> >
> > > 1. We could use metadata, e.g. "%px = alloca i32, align 4 !argument
> > > !i32 %x", followed by a store. There's still a little
> > > pattern-matching involved because the metadata is only a hint, but
> > > the intent in the IR is more explicit.
> >
> > > 2. We could change the way clang generates function definitions:
> > > instead of "define void @f(i32 %x)", generate "define void @f(i32*
> > > byval %px)" if the value is going to end up on the stack. This
> > > should work without any changes to the IR. This is a bad idea if
> > > we're trying to run optimizations because it obscures data flow,
> > > but
> > > it seems reasonable at -O0.
> >
> > 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!) annotations on the
> > arguments that communicates the *properties* of the source-language
> > types which affect the ABI. LLVM, then, would use that information
> > to implement the complete calling convention. No counting of numbers
> > of registers in Clang to put "inreg" markers in the right places, or
> > byval, or any of that sort of stuff it has to do today.
>
> > For example, on x86-64 SysV ABI, a complex classification algorithm
> > is run over the fields in an aggregate, to classify each eightbyte
> > quantity into one of several classes (MEMORY, INTEGER, SSE, etc).
> > That must run on the clang side, using source types, but it could
> > send the direct result of the classification to llvm, rather than
> > using it to mangle the prototype of the function in a secret
> > undocumented handshake using the few
> > seemingly-but-not-really-generic attributes that are available now.
> If we implement a system which worked like this, that would be
> spectacular! :-) The fact that so much of our ABI knowledge is locked up in
> Clang is fragile, causes difficulties with implementing other frontends,
> etc.
>
> -Hal
>
> > For that reason, I really don't like the second option you mention
> > above, as it requires clang to know more about exactly what the
> > calling convention decisions made by llvm are going to be.
>
> > Actually, I think byval should be deleted entirely. If you want to
> > pass by value...then, pass by value...
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
>
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20161210/37805fcc/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 10 Dec 2016 15:10:21 +0000
> From: Renato Golin via llvm-dev <llvm-dev at lists.llvm.org>
> To: Tom Stellard <tom at stellard.net>
> Cc: LLVM Dev <llvm-dev at lists.llvm.org>, Release-testers
> <release-testers at lists.llvm.org>, Clang Dev <
> cfe-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] [cfe-dev] 3.9.1-rc3 has been tagged
> Message-ID:
> <CAMSE1keh5qu1F1U0o-LY_XaKNG6QWrUFOhWtQiV=6YDg5BxqyA@
> mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 10 December 2016 at 00:48, Tom Stellard via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > I have tagged 3.9.1-rc3. The only differences from -rc2 were a few
> > bug fixes for ARM/AARCH64, so if you aren't testing either of these
> > I think it's safe to take this -rc off and what for -final.
> >
> > I'm hoping to do -final next week after I get the ARM test results.
>
> I'm on it.
>
> cheers,
> --renato
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 10 Dec 2016 09:28:50 -0600
> From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org>
> To: Eli Friedman <efriedma at codeaurora.org>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] RFC: Adding argument allocas
> Message-ID:
> <11002675.584.1481383726680.JavaMail.hfinkel at sapling5.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> ----- Original Message -----
>
> > From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org>
> > To: "Reid Kleckner" <rnk at google.com>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> > Sent: Friday, December 9, 2016 2:21:57 PM
> > Subject: Re: [llvm-dev] RFC: Adding argument allocas
>
> > On 12/9/2016 11:49 AM, Reid Kleckner wrote:
>
> > > 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
> > > > optimizations. Every feature we add to the IR makes it more
> > > > difficult to write IR transformations, and this really doesn't
> > > > seem
> > > > to carry its own weight.
> > >
> >
> > > I don't feel like it complicates our model that much, though.
> > > Passes
> > > already have to know that uninitialized allocas contain undef, and
> > > with this change they can contain a value. That doesn't seem very
> > > surprising. It is a fair point that we'd have to add new cases to
> > > code like llvm::FindAvailableLoadedValue, which looks for StoreInst
> > > but not AllocaInst.
> >
> > It's more that that... I mean, obviously you have to fix all the
> > places which assume allocas start off containing undef, but you're
> > also introducing the potential for missed optimizations by making
> > the store implicit. For example, consider:
>
> > void g(int *x);
> > __attribute((noinline)) void f(int y) {
> > y = 10;
> > g(&y);
> > }
> > void h() { f(134314); }
>
> > The argument to f is dead; there are two stores to y, and instcombine
> > will eliminate the first one. With extended allocas, we need a new
> > form of dead store elimination which transforms "alloca i32,
> > argument %x" -> "alloca i32".
>
> This is a good point, but it does not seem complicated to implement.
>
> -Hal
>
> > > > 2. We could change the way clang generates function definitions:
> > > > instead of "define void @f(i32 %x)", generate "define void
> > > > @f(i32*
> > > > byval %px)" if the value is going to end up on the stack. This
> > > > should work without any changes to the IR. This is a bad idea if
> > > > we're trying to run optimizations because it obscures data flow,
> > > > but
> > > > it seems reasonable at -O0.
> > >
> >
> > > This is problematic because it would break out "bitcode ABI"
> > > between
> > > optimized and debug builds. We've had problems in the past when the
> > > caller and callee disagree on whether an argument is a byval
> > > pointer
> > > or not, and instcombine will come along and try to simplify the
> > > casts: https://llvm.org/bugs/show_bug.cgi?id=21573
> >
> > If instcombine is breaking this somehow, it's a bug; we're not
> > supposed to eliminate bitcasts unless we can prove the signatures
> > are equivalent. Granted, this is a complicated transform which has
> > had a lot of bugs in the past.
>
> > -Eli
> > --
> > Employee of Qualcomm Innovation Center, Inc.
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> > Linux Foundation Collaborative Project
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
>
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20161210/4a69a971/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 10 Dec 2016 09:32:20 -0600
> From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org>
> To: Eli Friedman <efriedma at codeaurora.org>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] RFC: Adding argument allocas
> Message-ID:
> <10804386.590.1481383940297.JavaMail.hfinkel at sapling5.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> ----- Original Message -----
>
> > From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org>
> > To: "Reid Kleckner" <rnk at google.com>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> > Sent: Friday, December 9, 2016 12:30:34 PM
> > Subject: Re: [llvm-dev] RFC: Adding argument allocas
>
> > 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 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 should instead make
> > > our representation more accurately model reality. To me, it feels
> > > like this representation allows several good things to just "fall
> > > out" without any additional work, and that suggests it's a good
> > > representation.
> >
> > 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
> > optimizations.
> I'm not sure this is true. The instruction does write to memory, at least
> formally, but by definition the address of the alloca cannot yet have been
> used by anything else, and so no other memory access can alias with it. The
> write also can't trap. The alloca, as a result, does not even need to be
> tagged as writing to memory.
>
> -Hal
>
> > Every feature we add to the IR makes it more difficult to write IR
> > transformations, and this really doesn't seem to carry its own
> > weight.
>
> > A couple of other thoughts I had:
> > 1. We could use metadata, e.g. "%px = alloca i32, align 4 !argument
> > !i32 %x", followed by a store. There's still a little
> > pattern-matching involved because the metadata is only a hint, but
> > the intent in the IR is more explicit.
> > 2. We could change the way clang generates function definitions:
> > instead of "define void @f(i32 %x)", generate "define void @f(i32*
> > byval %px)" if the value is going to end up on the stack. This
> > should work without any changes to the IR. This is a bad idea if
> > we're trying to run optimizations because it obscures data flow, but
> > it seems reasonable at -O0.
>
> > -Eli
> > --
> > Employee of Qualcomm Innovation Center, Inc.
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> > Linux Foundation Collaborative Project
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
>
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20161210/53c5436d/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 10 Dec 2016 10:00:23 -0600
> From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org>
> To: Eli Friedman <efriedma at codeaurora.org>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] RFC: Adding argument allocas
> Message-ID:
> <20259972.609.1481385620617.JavaMail.hfinkel at sapling5.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> ----- Original Message -----
> > From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org>
> > To: "Reid Kleckner" <rnk at google.com>, "llvm-dev" <
> llvm-dev at lists.llvm.org>
> > Sent: Thursday, December 8, 2016 7:47:28 PM
> > Subject: Re: [llvm-dev] RFC: Adding argument allocas
> >
> > On 12/8/2016 5:05 PM, Reid Kleckner via llvm-dev wrote:
> > > If the semantics are the same, it begs the question, why don’t we
> > > pattern match the alloca and store to elide dead stores and reuse
> > > existing argument stack slots? My main preference for adding a new
> > > way
> > > to do this is that it gives us simpler and smaller code in debug
> > > builds, where we presumably don’t want to do this kind of pattern
> > > recognition. My experience with our -O0 codegen is that we do a lot
> > > of
> > > useless copies to initialize parameters, and this leads to larger
> > > output size, which slows things down. Having a more easily
> > > recognizable idiom for getting the storage behind parameters if it
> > > exists feels like a win.
> >
> > Why don't we want to do this kind of pattern recognition at -O0? We
> > can
> > do a fast scan which just looks at the entry block if you're
> > concerned
> > about compile-time.
> >
> > > One other questionable side benefit of doing this is that it would
> > > make it possible to implement va_start by taking the address of a
> > > parameter and doing pointer arithmetic. While that code is fairly
> > > invalid, it’s exactly what the MSVC STL headers do for 32-bit x86.
> > > If
> > > we make this work in Clang, we can remove our stdarg.h and vadefs.h
> > > wrapper headers. Users often pass flags that cause clang to skip
> > > these
> > > wrapper headers, and then they file bugs complaining that va lists
> > > don't work.
> >
> > This ignores the other reason why this doesn't work at the moment:
> > reading off the end of an alloca returns undef, whether or not the
> > actual pointer value points at the data you want. I mean, it's not
> > impossible to make it work, but it involves a bunch of unrelated
> > changes
> > which I don't think we want to pursue.
>
> I agree. Making reading past the end of an alloca defined behavior seems
> undesirable.
>
> -Hal
>
> >
> > -Eli
> >
> > --
> > Employee of Qualcomm Innovation Center, Inc.
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> > Linux Foundation Collaborative Project
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 10 Dec 2016 10:20:00 -0600
> From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org>
> To: Reid Kleckner <rnk at google.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] RFC: Adding argument allocas
> Message-ID:
> <6867190.632.1481386796505.JavaMail.hfinkel at sapling5.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> ----- 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 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 (
> > https://llvm.org/bugs/show_bug.cgi?id=26328 ). In many cases, the
> > memory allocation and store duplicate work already done by the
> > caller.
>
> > Case 1: The parameter is already being passed in memory. In this
> > case, we waste memory and do an extra load and store to copy it into
> > our own alloca. This is very common on 32-bit x86.
>
> > Case 2: On Win64, the caller pre-allocates shadow stack slots for all
> > register parameters. This allows the callee to “home” register
> > parameters to ease debugging and the implementation of variadic
> > functions. In this case, the store is not dead, but we fail to use
> > the pre-allocated memory.
>
> > Case 3: The parameter is a register parameter in a normal Sys-V ABI.
> > In this case, nothing is wasted. Both the memory and store are
> > needed.
>
> > I think we can improve our code for cases 1 and 2 by making it
> > possible to create allocas from parameters, and we can lower this
> > down to a regular stack object with a store in case 3. The syntax
> > for this would look like:
> > define void @f(i32 %x) {
> > %px = alloca i32, argument i32 %x, align 4
>
> > The semantics are the same as the following:
> > define void @f(i32 %x) {
>
> > %px = alloca i32, align 4
> > store i32 %x, i32* %px, align 4
>
> > It is invalid to make one of these argument allocas dynamic in any
> > way, either by using inalloca, using a dynamic element count, or
> > being outside the entry block.
>
> 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.
>
> -Hal
>
> > If the semantics are the same, it begs the question, why don’t we
> > pattern match the alloca and store to elide dead stores and reuse
> > existing argument stack slots? My main preference for adding a new
> > way to do this is that it gives us simpler and smaller code in debug
> > builds, where we presumably don’t want to do this kind of pattern
> > recognition. My experience with our -O0 codegen is that we do a lot
> > of useless copies to initialize parameters, and this leads to larger
> > output size, which slows things down. Having a more easily
> > recognizable idiom for getting the storage behind parameters if it
> > exists feels like a win.
>
> > Changing the semantics of alloca affects a lot of things, but I think
> > it makes sense to extend alloca here rather than a new intrinsic or
> > instruction that can create local variable stack memory that passes
> > would have to reason about. Here’s a list of things we’d need to
> > change off the top of my head:
> > 1. Inliner: When hoisting static allocas to the entry block, the
> > inliner will now strip the argument operand off of allocas and
> > insert the equivalent store at the inlined call site.
> > 2. Mem2reg: Loading from an argument alloca needs to produce the
> > argument value instead of undef.
> > 3. GVN: We need to apply the same logic to GVN and similar store to
> > load forwarding transforms.
> > 4. Instcombine: This transform has some simple store forwarding logic
> > that would need to be updated.
>
> > I’m sure there are more, but the changes seem worth it to get at
> > these low hanging opportunities.
>
> > One other questionable side benefit of doing this is that it would
> > make it possible to implement va_start by taking the address of a
> > parameter and doing pointer arithmetic. While that code is fairly
> > invalid, it’s exactly what the MSVC STL headers do for 32-bit x86.
> > If we make this work in Clang, we can remove our stdarg.h and
> > vadefs.h wrapper headers. Users often pass flags that cause clang to
> > skip these wrapper headers, and then they file bugs complaining that
> > va lists don't work.
>
> > At the end of the day, this feels like a straightforward engineering
> > improvement to LLVM, and it feels worth doing to me. Does anyone
> > feel otherwise or have any suggestions?
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
>
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20161210/e56670a8/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> llvm-dev mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> ------------------------------
>
> End of llvm-dev Digest, Vol 150, Issue 37
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/3c672cf8/attachment.html>
More information about the llvm-dev
mailing list