[PATCH] Implement aarch64 neon instruction class SIMD lsone and lsone-post - LLVM

Jiangning Liu liujiangning1 at gmail.com
Sun Nov 24 22:55:48 PST 2013


Tim,

Sorry, I'm not sure I understand your point here. See my comments below,
and I'm still trying to understand your point.

Thanks,
-Jiangning

2013/11/22 Tim Northover <t.p.northover at gmail.com>

> > As I mentioned previously in this email thread, the scenario for this
> case
> > is different from table lookup. We do have instruction directly map to
> this
> > intrinsic directly. The operand conversion between 64-bit and 128-bit
> should
> > be able to be solved by EXTRACT_SUBREG and SUBREG_TO_REG,
>
> It certainly *can* be, and my complaint isn't about that. I love
> EXTRACT and friends since they're often free!


This sounds good, and we are suggesting using EXTRACT_SUBREG and friends,
so we are on the same page, right?


> My complaint is that
> we're effectively introducing an unnecessary set of intrinsics


I don't understand about this. Can you explicitly point out what
intrinsics names are really unnecessary?


> (OK, so
> they have the same base name as ones that are more useful[*], but
> they're still extra backend burden)


Do you mean using EXTRACT_SUBREG and friends is a backend burden?


> for something that's representable
> at the IR level.
>
> Cheers.
>
> Tim.
>
> [*] Though, now that I think of it, even those ought to be expressible
> as IR. Something for the future, I suppose.
>



-- 
Thanks,
-Jiangning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131125/306a3f45/attachment.html>


More information about the llvm-commits mailing list