[PATCH] Implement aarch64 neon instruction class AdvSIMD (by element) - Clang

Jiangning Liu liujiangning1 at gmail.com
Tue Oct 1 18:07:15 PDT 2013

Hi Ana,

In the clang changes, some of the intrinsics name carry a 'q' at the end of
> the base function name ( e..g., vmla_laneq). As a consequence you have to
> define a Q and non-Q version of the intrinsic declaration.
> Do you think it is better to add the 'q' using a size modifier like "128b
> but mangling 'q' at the end of base neon function name". I did something
> like that for the scalar by element intrinsics where I need to generate
> names like 'vmulxd_laneq_f64'.
> But in your case it seems you need 'q' both before the first '_' and at
> the end of the base neon function name.  Is that the reason you did not use
> a type modifier? You would need yet another size modifier like '128b but
> mangling 'q' at both places".

Yes. This is one of the reasons.

Also, my thought is we should avoid mixing the 'q' for specifying the
result size of an ACLE intrinsic with the 'q' in 'laneq', because
1) The former one is more general for all intrinsics, and the latter is
only for 'by element' class.
2) If we introduce another 'q' semantic, we would need to add more codes of
automatically inserting the 'q' after 'lane' in NeonEmitter.cpp . I think
it would be easy to make mistake and hard to be maintained by mixing those
two 'q's.
3) It's quite natural to introduce a new proto letter 'j (force 'Q' size
modifier) to describe the inverse semantic of proto letter 'g (ignore 'Q'
size modifier)'.

For your case, do you have to add a new size modifier? Can the new proto
letter 'j' work for you?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131002/80f4cff6/attachment.html>

More information about the cfe-commits mailing list