This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
aarch64 asm operand checking
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: <marcus dot shawcroft at arm dot com>,<richard dot earnshaw at arm dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Thu, 29 Jan 2015 07:54:26 +0000
- Subject: aarch64 asm operand checking
- Authentication-results: sourceware.org; auth=none
Hello,
in the Xen project we had (meanwhile fixed) code like this (meant to
be uniform between 32- and 64-bit):
static inline int fls(unsigned int x) {
int ret;
asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
return BITS_PER_LONG - ret;
}
Being mainly an x86 person, when I first saw this I didn't understand
how this could be correct, as for aarch64 BITS_PER_LONG is 64, and
both operands being 32-bit I expected "clz w<a>, w<b>" to result.
Yet I had to learn that no matter what size the C operands, x<n>
registers are always being picked. Which still doesn't mean the above
is correct - a suitable call chain can leave a previous operation's
64-bit result unconverted, making the above produce a supposedly
impossible result greater than 32.
Therefore I wonder whether aarch64_print_operand() shouldn't,
when neither the 'x' not the 'w' modifier is given, either - like
ix86_print_operand() (via print_reg()) - honor
GET_MODE_SIZE (GET_MODE (x)), or at the very least warn
when that one is more narrow than 64 bits. And yes, I realize that
this isn't going to be optimal (and could even be considered
inconsistent) as there's no way to express the low half word or
byte of a general register, i.e. operands more narrow than 32 bits
couldn't be fully checked without also knowing/evaluating the
instruction suffix, e.g. by introducing a 'z' operand modifier like
x86 has, or extending the existing 'e' one.
Jan