llvm dev - May 2013 - [LLVMdev] Definition of RegisterClass for load instruction in Thumb2

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


On May 23, 2013, at 11:51 AM, Tim Northover <tnorthover at apple.com>
wrote:
> 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.

On May 23, 2013, at 8:51 AM, Tim Northover <tnorthover at apple.com>
wrote:
> 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
> 
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130529/770c8b4f/attachment.html>