<div dir="ltr">> <span style="font-size:13px">Is the problem specific to misaligned loads and stores? Because that seems much easier to solve.</span><div><span style="font-size:13px"><br></span></div><div>Mostly, but with a twist: Misaligned loads/stores are fine if your target supports them (I don't imagine they're a problem on x86), but as far as I know we don't have a way to express to the mid-level optimisers whether a misaligned load/store will be *bad* on the current target CPU (in the sense that SelectionDAG will have to expand it to something much larger). The relevant information is currently on TargetLowering. Maybe we need to move it somewhere more accessible.</div><div><br></div><div>> <span style="font-size:13px">But why does lowering as memcpy help? Essentially, I don't understand why we can't use exactly the same lowering strategy that memcpy (or memmove for that matter) would use and get the same effect.</span></div><div><br></div><div>As far as I can see the only way memcpy helps is by conveying that the source and dest are non-overlapping. (None of this applies to memmove - as far as I know that function can be converted to a load/store pair with no loss of information).</div><div>Take the simple case where memcpy lowering is just going to issue a series of load-byte / store-byte instructions: That's not a legal way to to lower an arbitrary load/store pair, since in the later case the source and dest may overlap, but it is legal for a memcpy.</div><div><br></div><div>> <span style="font-size:13px">FWIW, my suggestion about using legal integer types should not raise the cap at all, it should lower it on specific targets where we can't actually fit an 8-byte integer in a register.</span></div><div><span style="font-size:13px"><br></span></div><div>Oh, right. Sorry - I mis-parsed that as legal primitive type, and imagined applying it to vector types. That raises an interesting question though: Would it be useful to apply this logic to vector types too?</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 11:11 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="">On Wed, Apr 8, 2015 at 10:57 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Chandler,<div><br></div><div>Not as easy as I was hoping then.</div></div><div dir="ltr"><div><br></div><div>> <span style="font-size:13px">Do you see any other way to solve the problem of non-overlapping information?</span></div><div><br></div></div><div dir="ltr"><div>I'll have to do some reading. If there's any aliasing metadata that we can attach to express that the pointers are disjoint, that would work: In SelectionDAGBuilder we could detect disjoint, misaligned load/store pairs where the load has no other users and use the memcpy expansion instead.<br></div></div></blockquote><div><br></div></span><div>Is the problem specific to misaligned loads and stores? Because that seems much easier to solve.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div><div dir="ltr"><div><div><br></div></div><div>> Is an under aligned memcpy really that much better than an under aligned load and store??? <br></div><div class="gmail_extra"><br></div></div><div dir="ltr"><div class="gmail_extra">It saves a bit of shifting and masking as you try to reconstruct the full iN value in a register.</div></div></blockquote><div><br></div></span><div>But why does lowering as memcpy help? Essentially, I don't understand why we can't use exactly the same lowering strategy that memcpy (or memmove for that matter) would use and get the same effect.</div><div><br></div><div>If your concern is code size, I'm honestly still surprised that memcpy is smaller, but fine, emit the call *whenever* you end up with misaligned loads and stores?</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> This would be exacerbated if we raised the size cap. I'll see if I can get you some numbers.</div></div></blockquote><div><br></div></span><div>FWIW, my suggestion about using legal integer types should not raise the cap at all, it should lower it on specific targets where we can't actually fit an 8-byte integer in a register.</div><div><br></div><div>Anyways, I don't think we need numbers if the primary concern is misaligned loads and stores. I just think that there has to be *some* lowering strategy that works in general for misaligned loads and stores and is no worse than calling memcpy.</div></div></div>
</blockquote></div><br></div>