diff options
author | David Green <david.green@arm.com> | 2019-08-04 10:18:15 +0000 |
---|---|---|
committer | David Green <david.green@arm.com> | 2019-08-04 10:18:15 +0000 |
commit | 91296295d02e26830e9e0cbe03f02982c90e0056 (patch) | |
tree | 42a7c200464d65f1d4c4f43146829f39310def1b /llvm/lib/Support/CodeGenCoverage.cpp | |
parent | 037861b2309268245a801b9fc167097d83c8d905 (diff) | |
download | llvm-91296295d02e26830e9e0cbe03f02982c90e0056.zip llvm-91296295d02e26830e9e0cbe03f02982c90e0056.tar.gz llvm-91296295d02e26830e9e0cbe03f02982c90e0056.tar.bz2 |
[ARM] MVE big endian bitcasts
This adds big endian MVE patterns for bitcasts. They are defined in llvm as
being the same as a store of the existing type and the load into the new. This
means that they have to become a VREV between the two types, working in the
same way that NEON works in big-endian. This also adds some example tests for
bigendian, showing where code is and isn't different.
The main difference, especially from a testing perspective is that vectors are
passed as v2f64, and so are VREV into and out of call arguments, and the
parameters are passed in a v2f64 format. Same happens for inline assembly where
the register class is used, so it is VREV to a v16i8.
So some of this is probably not correct yet, but it is (mostly) self-consistent
and seems to be consistent with how llvm treats vectors. The rest we can
hopefully fix later. More details about big endian neon can be found in
https://llvm.org/docs/BigEndianNEON.html.
Differential Revision: https://reviews.llvm.org/D65581
llvm-svn: 367780
Diffstat (limited to 'llvm/lib/Support/CodeGenCoverage.cpp')
0 files changed, 0 insertions, 0 deletions