<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 21, 2018 at 9:11 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"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Except for one bit, which was that it requires correct typing of load/store<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<br>
 This is a valid concern because currently nor LLVM nor clang respect this<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<br>
<br>
What are the places in llvm and clang that do this kind of type punning? So<br>
far I only encountered them in SROA and in memcpys generated by clang. I<br>
would be very interested in getting rid of them.<br>
</blockquote>
<br></span>
Besides the ones you and Daniel mentioned there's also GVN. If GVN concludes that a load of a pointer and a load of an integer are equal, e.g. (load i64**) = (load i64*), then it will get rid of one of the loads and insert an inttoptr/ptrtoint.<br>
This is incorrect (in our memory model, at least), since GVN is essentially introducing implicit casts with the memory operations. One of the consequences of memory models that support implicit casts is that they make dead store eliminiation illegal in general, which is not really desirable (more details in the paper draft I sent you).</blockquote><div> <div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;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">Note:This is also illegal in non-integral pointer types, IIRC, and so as that becomes less experimental, this has to be changed at least for that.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;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"><br></div><br class="gmail-Apple-interchange-newline"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br>
Would you be able to post a link to these discussions? I would like to<br>
understand the potential cons of such change.<br>
</blockquote>
<br></span>
Sorry, most of the discussions were off-line.<br>
<br>
Advantages include of disable type punning include:<br>
 - Make LLVM IR (more) sound and thus enable automatic verification of optimizations<br>
 - Enable additional optimizations. Daniel mentioned better AA. There are other things, like better tracking of padding.  In general, merging multiple variables in a single variable confuses most dataflow analyses.<br>
<br>
Disadvtanges:<br>
 - Potential for more insert/select element instructions (although fewer bitwise operations to pull out elements)<br>
 - Need a few fixes to Clang for the ABI lowering stuff<br>
<br>
I'm surely forgetting something, but that's what on the top of my head.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div> <br></div></div></div></div>