[PATCH] Optimize insertqi when we copy all the lower 64 bits.
filcab+llvm.phabricator at gmail.com
Wed Apr 23 14:19:03 PDT 2014
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
Which of these would be better?
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...
More information about the llvm-commits