[PATCH] D96394: [AVR] Improve inline assembly
Ben Shi via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Mar 4 04:49:44 PST 2021
benshi001 added a comment.
In D96394#2602957 <https://reviews.llvm.org/D96394#2602957>, @aykevl wrote:
> I don't really understand what you're doing here. For example:
>
> case 'd': // Upper registers r16..r31.
> if (VT == MVT::i8)
> return std::make_pair(0U, &AVR::LD8RegClass);
> else if (VT == MVT::i16)
> return std::make_pair(0U, &AVR::DLDREGSRegClass);
> break;
>
> If I'm reading https://www.nongnu.org/avr-libc/user-manual/inline_asm.html correctly, this appears to imply an 8-bit register, but you're also implementing support for 16-bit registers. Why?
Although I expect 'd' constraint to imply an 8-bit variable, I can not prevent user specifies a 16-bit variable as `d` constraint on purpose. If `AVR::LD8RegClass` is returned for a 16-bit variable with `d`, llvm will crash as reported in https://bugs.llvm.org/show_bug.cgi?id=48480 .
The logic here is,
1. return `AVR::LD8RegClass` for 8-bit `d`, which is correct and expected.
2. return `AVR::DLDREGSRegClass` for 16-bit `d`, which is not expected, but also correct assembly.
3. `break` to llvm's default process for 32/64-bit `d`, which is not expected, but also wrong assembly.
Actually avr-gcc accepts all 8-16-32-64-bit `d` and generates all correct assembly. And I just fix 8-16 bit in the patch, and left 32-64-bit in furture patches.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D96394/new/
https://reviews.llvm.org/D96394
More information about the llvm-commits
mailing list