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