<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"James Y Knight via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"Eli Friedman" <efriedma@codeaurora.org><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Friday, December 9, 2016 6:04:18 PM<br><b>Subject: </b>Re: [llvm-dev] RFC: Adding argument allocas<br><br><div dir="auto"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 9, 2016 at 1:30 PM, Friedman, Eli 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: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><span class="m_-7267374558098249111m_-2252950334366824260m_-9069867827564364381gmail-">
<div class="m_-7267374558098249111m_-2252950334366824260m_-9069867827564364381gmail-m_-7117265439172886674moz-cite-prefix">On 12/9/2016 8:45 AM, Reid Kleckner
wrote:<br>
</div>
<blockquote>
<div dir="ltr">On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;">
<div>So IIUC basically the *only* reason for this IR change
is that we don’t want to pattern match in debug build?</div>
<div>I don't understand right now why we wouldn’t want to do
this?</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br></span>
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.<br>
<br>
A couple of other thoughts I had:<br>
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.<br>
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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div id="DWT7158">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.</div></div></div></div></div></blockquote>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><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="auto"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div><div>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.</div></div><div dir="auto"><br></div><div dir="auto">Actually, I think byval should be deleted entirely. If you want to pass by value...then, pass by value...</div></div></div></div></div>
<br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>