[llvm-dev] analyzePhysReg question

Smith, Kevin B via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 3 17:11:47 PST 2015



>-----Original Message-----
>From: Quentin Colombet [mailto:qcolombet at apple.com]
>Sent: Thursday, December 03, 2015 4:43 PM
>To: Smith, Kevin B <kevin.b.smith at intel.com>
>Cc: llvm-dev at lists.llvm.org
>Subject: Re: [llvm-dev] analyzePhysReg question
>
>
>> On Dec 3, 2015, at 4:35 PM, Smith, Kevin B via llvm-dev <llvm-
>dev at lists.llvm.org> wrote:
>>
>> I am looking at results from analyzePhysReg, and am getting results a little
>different than I expected for x86.
>>
>> The call to this is coming from this code in
>llvm::MachineBasicBlock::computeRegisterLiveness
>> 1163          MachineOperandIteratorBase::PhysRegInfo Analysis =
>> 1164            ConstMIOperands(I).analyzePhysReg(Reg, TRI);
>>
>> The instruction I being analyzed is:
>>  %BX<def> = MOV16rm %EDI, 2, %ECX, 0, %noreg;
>mem:LD2[%arrayidx98](tbaa=!18)
>>
>> and the Reg being passed in is 21, which is EBX.  The result I get back for
>is:
>>
>> Analysis: {Clobbers = true, Defines = true, Reads = false, ReadsOverlap =
>false,
>>  DefinesDead = false, Kills = false}
>>
>> It seems based on the comment in the definition of PhysRegInfo.Defines,
>that Defines should only be true if Reg or a super-register of Reg is
>> defined.  BX is not a super-register of EBX, so it seemed like Defines
>should be false here, while Clobbers is correct as true.
>
>I believe the documentation is wrong here.
>EBX is partly defined, so to me Defines == true is conservatively correct
>here.
>My guess, but I haven’t checked the code, is that super-register should be
>understood as any alias of Reg.
>
>Worth checking.
>
>Q.

I agree EBX is partly defined, but I think that is what Clobbers is for.  The interface for isSuperRegister
certainly makes a pretty clear distinction between something being a superRegister and something being an
overlapping register.  What do you think I should be checking to understand the assumptions/expectations better?
 
>
>>
>> I wanted to be sure that I wasn't missing something about the interface
>definition/expectation.
>>
>> Thanks,
>> Kevin Smith
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



More information about the llvm-dev mailing list