[PATCH] Gut InstCombiner::SimplifyMemTransfer.

[Chandler Carruth]

On Wed, Apr 8, 2015 at 10:57 PM Lang Hames <lhames at gmail.com> wrote:

> Hi Chandler,
>
> Not as easy as I was hoping then.
>
> > Do you see any other way to solve the problem of non-overlapping
> information?
>
> 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.
>

Is the problem specific to misaligned loads and stores? Because that seems
much easier to solve.


>
> > Is an under aligned memcpy really that much better than an under aligned
> load and store???
>
> It saves a bit of shifting and masking as you try to reconstruct the full
> iN value in a register.
>

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.

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?


> This would be exacerbated if we raised the size cap. I'll see if I can get
> you some numbers.
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150409/1b4f5383/attachment.html>