[MC] Requiring MCAsmInfo for MCExpr evaluation?
ahmed.bougacha at gmail.com
Fri Apr 24 10:42:35 PDT 2015
Jim, Tim, Kevin: I want to change the MCExpr Shr constant evaluation
to be either logical or arithmetic, depending on the target.
It's always arithmetic currently, and 1) that doesn't match current
gas; 2) it leads to unexpected behavior like:
$ echo 'movz x1, ((0xfffffffffffffffc & 0xffff000000000000) >>
48), LSL #48' | llvm-mc -arch aarch64
<stdin>:1:10: error: immediate must be an integer in range [0, 65535].
movz x1, ((0xfffffffffffffffc & 0xffff000000000000) >> 48), LSL #48
I believe it makes sense to update all targets, but I think that ship
has sailed for X86/ARM Darwin, where there's a point to be made for
backwards compatibility with gas 1.38 (`as -Q').
For AArch64 Darwin however, would it make sense to use LShr?
On Fri, Apr 24, 2015 at 8:07 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> + bool useLogicalShr()
> shouldUseLogicalShr() is probably a bit better.
> This changes the behaviour of AArch64 MachO, right? Can we leave that
> as is for now and change it in another patch?
> On 22 April 2015 at 20:49, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote:
>> On Wed, Apr 22, 2015 at 2:43 PM, Rafael Espíndola
>> <rafael.espindola at gmail.com> wrote:
>>> Looks like we have to store more information in the expressions
>>> themselves. Would changing
>>> Lhr, ///< Shift right (arithmetic or logical, depending on target)
>>> Lshr, ///< Logical shift right
>>> Ashr, ///< Arithmetic shift right
>>> solve the problem?
>> Yup, how about the attached patch?
>> I tried binutils v2.24 aarch64-linux-gnu-as, and it has the same
>> behavior. On Darwin, the only AArch64 assembler is LLVM, and the
>> previous behavior was wrong, so the change is fine.
>> We'll see about other targets. I looked at the assemblers I had lying
>> around (ARM, AArch64, X86; darwin, linux) and AFAIK, only ancient GAS
>> (I tried the last Apple-bundled one, v1.38) does the AShr.
>> Notably, binutils v2.24 for arm-linux-gnueabihf and x86_64-linux-gnu
>> both do the LShr. So it's probably fine to do the switch there too,
>> at the very least?
>> Are there even targets where AShr is the intended behavior, and not
>> some 20yo GAS bug?
More information about the llvm-commits