[llvm-dev] RFC: Adding argument allocas

[Reid Kleckner via llvm-dev]

On Fri, Dec 9, 2016 at 11:56 AM, Philip Reames <listmail at philipreames.com>
wrote:

> On 12/09/2016 08:45 AM, Reid Kleckner via llvm-dev 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.
>
> I'm concerned by this response on multiple levels.  I agree Mehdi that the
> proposed IR change seems to be solving a (relatively minor) optimization
> problem with an IR change.  We generally expect our IR changes to be well
> justified and this doesn't even come close to me.  More than that, I'm
> really concerned about the assumption that the IR should be a close fit
> *for a particular frontend* in a *particular mode of operation*.  We have
> tried very hard to keep the IR generic enough to be useful by many language
> frontends and this would seem to give up on that goal.  That is deeply
> concerning  to me.
>

I wouldn't be doing this if I thought it was a minor optimization, but in
fairness, I haven't measured how much of a win this is yet. The fact that
this change solves two separate but related problems in optimized code and
unoptimized code is what makes me think this is a good idea.

I don't see how my proposal favors a particular frontend. The pattern of
creating an alloca and storing to it is the recommended way to create
mutable local variables (
http://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas). We can
document the new more efficient idiom if we decide to implement it.
Frontends that generate SSA directly are interesting, but I think it's fair
for us to optimize for frontends using allocas.

This should also be a generic improvement across all targets, even if it is
more of a win on targets with fewer register parameters. If you have enough
arguments, eventually some of them will be passed in memory, unless you
have a virtual ISA with an infinite register file.


> As it stands right now, based on what I've seen to date in discussion, I
> would be strongly opposed to this proposal.
>

Darn. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161209/4017aded/attachment.html>