[PATCH] Optimize insertqi when we copy all the lower 64 bits.

[Filipe Cabecinhas]

How could we use insertelement here?
Should we just (on the clang side) bitcast the vectors to <128 x i1> and
use extractelement + insertelement?
That seems… hard to match on the output side.

The instruction copies _bits_ from one vector to another. We can
special-case it when we're copying from an 8/16/32/64 bit boundary, for a
multiple of that amount of bits, but doing the generic instruction in IR
doesn't seem that easy to do.

I've also looked a bit more at SelectionDAG and I think it might be worth
it to move this optimization there. But I don't know if it could handle the
sequence of insertqi -> copy source vector, when the insertqi ranges add up
to [0,64).

Which of these would be better?

Regards,
  Filipe


On Wed, Apr 23, 2014 at 9:16 AM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

>
>
> Sent from my iPhone
>
> > On Apr 23, 2014, at 12:08, Nadav Rotem <nrotem at apple.com> wrote:
> >
> >
> >> On Apr 23, 2014, at 6:56 AM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
> >>
> >>> On 15 April 2014 14:04, Nadav Rotem <nrotem at apple.com> wrote:
> >>> Hi Filipe,
> >>>
> >>> Why is this an IR-level transform? Could you implement this in
> SelectionDAG ?
> >>
> >> What is the advantage of doing this at SelectionDAG? Since this is an
> >> intrinsic, we know all that we need at the IR level already. IR also
> >> has the advantage of opening the potential for further optimizations
> > It is not clear to me why we represent this intrinsic as an IR-level
> intrinsic and not as a regular insertelement instruction. We already have
> IR-level optimizations on insertelement and I prefer not to duplicate all
> of them.
> >
>
> That I fully agree with. If the operation can be represented with generic
> ir that is by far the best solution.
>
>
> >> an has much better testing than SelecetionDAG.
> >>
> >> Cheers,
> >> Rafael
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140423/6aa97ad7/attachment.html>