[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/cfe-commits/attachments/20131125/306a3f45/attachment.html>
More information about the cfe-commits
mailing list