<div dir="ltr">I wrote up this optimization as an LLVM IR pass last month, actually:<div><a href="https://code.google.com/p/foster/source/browse/compiler/llvm/passes/BitcastLoadRecognizer.cpp">https://code.google.com/p/foster/source/browse/compiler/llvm/passes/BitcastLoadRecognizer.cpp</a><br>

</div><div><br></div><div>It recognizes trees of `or' operations where the leaves are (buf[v+c] << c * sizeof(buf[0])).</div><div><br></div><div>There are a few improvements needed to make it fit for general consumption; it assumes (without checking) that it's targeting a little-endian architecture, and it doesn't propagate alignment or inbounds information from loads. It also does not recognize/generate byte swaps, though it would be a pretty trivial extension to do so. It might also be nice to have the dual optimization to coalesce stores rather than loads.</div>

<div><br></div><div>If anyone wants to use this as a starting point for a patch, feel free!</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 7:53 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">----- Original Message -----<br>
> On Mon, Oct 28, 2013 at 10:09 AM, James Courtier-Dutton<br>
> <<a href="mailto:james.dutton@gmail.com">james.dutton@gmail.com</a>> wrote:<br>
> > My guess is that this is a missed optimization, but in real life,<br>
> > all<br>
> > projects i have worked fix this in the C or C++ code using macros<br>
> > that<br>
> > change what instructions are used based on target platform and its<br>
> > endedness.<br>
><br>
> One reason for writing code like this, i.e. explicitly spelling out<br>
> the accesses to the individual bytes, would be to allow compile-time<br>
> evaluation of the fragment in the D programming language, where<br>
> arbitrarily reinterpreting memory is not supported (although<br>
> integer->integer pointer casts might be supported at some point).<br>
><br>
> Would a patch adding the capability to lower this to InstCombine or<br>
> similar have a chance of being accepted, or would that be considered<br>
> to be too rare a spacial case to be worth the added complexity?<br>
<br>
</div>I think that a patch for this would be great; I've seen plenty of real-life deserialization code that looks like this.<br>
<br>
FWIW, some patterns like this (byte swapping, for example), are matched during CodeGen (see DAGCombiner::visitOR in lib/CodeGen/SelectionDAG/DAGCombiner.cpp), but there is no reason that this pattern cannot be recognized and canonicalized early in the IR (and I think that it should be).<br>


<br>
 -Hal<br>
<div class="im HOEnZb"><br>
><br>
> David<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>