<div dir="ltr">Hi Nuno,<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Except for one bit, which was that it requires correct typing of load/store operations. That is, if you load an i32, it means you are loading a single 32-bit integer, not two 16-bit integers or something else.</span><br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">This is a valid concern because currently nor LLVM nor clang respect this property. Clang may pass several parameters as a single variable, LLVM has optimizations that combine several loads into a single integer load, etc.</span></blockquote><div><br></div><div>What are the places in llvm and clang that do this kind of type punning? So far I only encountered them in SROA and in memcpys generated by clang. I would be very interested in getting rid of them.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">My personal opinion is that we should fix LLVM/clang such that memory operations are properly typed. We have proposed this through the use of vectors. While there were supporters for this approach, there wasn't a consensus.  To be fair, we didn't implement a complete prototype for this idea nor did we conduct a thorough discussion.</span></blockquote><div><br>Would you be able to post a link to these discussions? I would like to understand the potential cons of such change.<br><br>Best,<br>Jakub</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 20, 2018 at 6:28 AM, Nuno Lopes 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"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 20 March 2018 at 09:39, Nuno Lopes via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Let me give you my view of the status:<br>
The proposal you mentioned was, I believe, well understood and accepted.<br>
Except for one bit, which was that it requires correct typing of load/store<br>
operations. That is, if you load an i32, it means you are loading a single<br>
32-bit integer, not two 16-bit integers or something else.<br>
<br>
This is a valid concern because currently nor LLVM nor clang respect this<br>
property. Clang may pass several parameters as a single variable, LLVM has<br>
optimizations that combine several loads into a single integer load, etc.<br>
So in some places of LLVM it is assumed that ix is just a bag of x bits and<br>
not an integer of x bits.<br>
<br>
My personal opinion is that we should fix LLVM/clang such that memory<br>
operations are properly typed. We have proposed this through the use of<br>
vectors. While there were supporters for this approach, there wasn't a<br>
consensus.  To be fair, we didn't implement a complete prototype for this<br>
idea nor did we conduct a thorough discussion.<br>
</blockquote>
<br>
Do you have a link to this vector-based proposal? Suppose Clang<br>
currently lowers a parameter of type struct { int32_t, int8_t, int8_t,<br>
int8_t, int8_t } to i64, neither changing this to <8 x i8> or <2 *<br>
i32> seems correct - but perhaps one of those options is close enough<br>
for your requirements?. This is a disruptive change of course: there<br>
is an often under-specified contract between the frontend and target<br>
backend on the ABI lowering of function parameters and return values.<br>
Changing the requirements here will require changes for every LLVM<br>
language frontend. If a big shake-up of this part of LLVM is the way<br>
forwards, it would probably be worth taking the time to consider all<br>
possible options for improvement.<br>
</blockquote>
<br></div></div>
I just realized there isn't much information about this proposal. The best I could find is slides 23-24 of this: <a href="http://llvm.org/devmtg/2016-11/Slides/Lopes-LongLivePoison.pdf" rel="noreferrer" target="_blank">http://llvm.org/devmtg/2016-11<wbr>/Slides/Lopes-LongLivePoison.<wbr>pdf</a><br>
<br>
The basic idea is that instead of accessing 2 shorts as i32, you could access them as <2 x i16>. In case of structures with different element types, you would need to use structures, which LLVM also supports. For the proposal to be correct, you can slice a value into smaller vector elements, but you cannot share a vector element across two values.<br>
For example, representing you struct example as <8 x i8> would be correct, but not as <2 x i32>. Or we can use structures to have elements of the exact size.<br>
<br>
You are right that the ABI lowering and the contracts for vectors are a bit underspecified. That's probably one of the reasons why vectors of i1s crash and generate bad code frequently. Is there padding between vector elements or not? Or are sub-word elements packed somehow?<br>
<br>
Nuno<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div>Jakub Kuderski</div></div>
</div>