Hi,
I have a question about the definitions of t2LDRSB and t2LDRSB_PRE in ARMInstrThumb2.td :
I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced?
defm t2LDRSB : T2I_ld<1, 0b00, "ldrsb", IIC_iLoad_bh_i, IIC_iLoad_bh_si,
rGPR, UnOpFrag<(sextloadi8 node:$Src)>>;
def t2LDRSB_PRE : T2Ipreldst<1, 0b00, 1, 1, (outs GPR:$Rt, GPR:$Rn_wb),
(ins t2addrmode_imm8:$addr),
AddrModeT2_i8, IndexModePre, IIC_iLoad_bh_iu,
"ldrsb", "\t$Rt, $addr!", "$addr.base = $Rn_wb",
> {
let AsmMatchConverter = "cvtLdWriteBackRegT2AddrModeImm8";
}
Thanks,
Junbum
Hi Junbum,
I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced?
They're not allocated during CodeGen because of the Reserved.set(…) calls in ARMBaseRegisterInfo.cpp.
That said, this inconsistency is probably wrong anyway (or at best an approximation to reality) because it affects what the assembler supports. For example
ldrsb sp, [r0]!
is allowed, but
ldrsb sp, [r0]
is forbidden. I think they should both be UNPREDICTABLE (though this is an understandable error; support for unpredictable is in its early stages).
Annoyingly, there is *some* distinction between the writeback and non-writeback versions. Fixing it properly might get hairy rather quickly.
Tim.
Thank you for the answer.
What is the main reason of allowing this inconsistency in the td file? I guess that's because of the "some" distinction between the writeback and non-writeback versions. Is there any benefit from the inconsistency by using GRP in .td file and freezing lr and pc during register allocation in writeback version?
Thanks,
Junbum
Hi,
What is the main reason of allowing this inconsistency in the td file? I guess that's because of the "some" distinction between the writeback and non-writeback versions.
I think so. LLVM is a bona-fide assembler as well as being a compiler, and a user will expect to be able to assemble the odd, different corner cases even if they're useless to a compiler (because SP is reserved for a special use, for example).
Is there any benefit from the inconsistency by using GRP in .td file and freezing lr and pc during register allocation in writeback version?
I don't think there's any direct benefit in this case (since it's wrong) but in general it's the only way to get the assembler to behave properly.
Cheers.
Tim.
Hi Junbum,
I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced?
They’re not allocated during CodeGen because of the Reserved.set(…) calls in ARMBaseRegisterInfo.cpp.
That said, this inconsistency is probably wrong anyway (or at best an approximation to reality) because it affects what the assembler supports. For example
ldrsb sp, [r0]!
is allowed, but
ldrsb sp, [r0]
is forbidden. I think they should both be UNPREDICTABLE (though this is an understandable error; support for unpredictable is in its early stages).
Annoyingly, there is some distinction between the writeback and non-writeback versions. Fixing it properly might get hairy rather quickly.
“hairy” is an understatement. The way we model the ARM load/store instructions, especially the NEON ones, in LLVM is a bit of a mess. I tried digging in a while back and only got partway through before running out of time. It’s still on my list of cleanups I’d love to do someday…
-Jim