[LLVMdev] MachineSink and EFLAGS

[Galanov, Sergey]

Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value.

For an example we can look no further than the actual test which has been disabled after the fix (llvm/test/Codegen/X86/sink-hoist.ll, function zzz). 

BB#0: derived from LLVM BB %entry
	%vreg0<def> = MOV8rm <fi#-2>, 1, %noreg, 0, %noreg; mem:LD1[FixedStack-2](align=4) GR8:%vreg0
	%vreg1<def> = AND8ri %vreg0, 127, %EFLAGS<imp-def,dead>; GR8:%vreg1,%vreg0
	%vreg2<def> = OR8ri %vreg0, -128, %EFLAGS<imp-def,dead>; GR8:%vreg2,%vreg0
	CMP8mi <fi#-1>, 1, %noreg, 0, %noreg, 0, %EFLAGS<imp-def>; mem:LD1[FixedStack-1](align=8)
	%vreg3<def> = CMOV_GR8 %vreg2<kill>, %vreg1<kill>, 4, %EFLAGS<imp-def,dead>, %EFLAGS<imp-use>; GR8:%vreg3,%vreg2,%vreg1
	%vreg4<def> = MOVZX32rr8 %vreg3<kill>; GR32:%vreg4 GR8:%vreg3
	%EAX<def> = COPY %vreg4; GR32:%vreg4
	RET

CMOV_GR8 instruction has EFLAGS use which is not marked kill, and that's why EFLAGS is marked live-in in the new blocks created when lowering the pseudo cmov. But besides that it also has an imp-def of EFLAGS marked dead. How can an instruction use and define the same register with def being dead and use not being killed? I believe this is happening just because proper liveness information is not calculated at that point, but anyway we can treat EFLAGS as if it was marked killed in this case, can't we? 

So this is precisely my proposal: don't mark EFLAGS live-in in the new blocks in EmitLoweredSelect if EFLAGS is a dead def of the pseudo cmov.

-----Original Message-----
From: Bill Wendling [mailto:wendling at apple.com] 
Sent: Saturday, June 04, 2011 2:32 AM
To: Galanov, Sergey
Cc: Jakob Stoklund Olesen; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] MachineSink and EFLAGS

On Jun 3, 2011, at 2:59 AM, Galanov, Sergey wrote:

> Hi, Bill and Jakob.
> 
> I don't quite understand. I am talking about CMOV_GR* instructions which are conservatively marked as clobbering EFLAGS in X86InstrCompiler.td. Doesn't that mean there cannot be any use of EFLAGS in subsequent instructions before it is defined by some other instruction?
> 
> I also don't understand the remark about resetting EFLAGS. What kind of reset is meant? In case of normal branch instructions there is no specific reset instruction and EFLAGS is not marked live-in in successor blocks. How is that different from our case?
> 
Perhaps it was a misunderstanding. :) Anyway, if an instruction (CMOV_GR* in this case) clobbers the value in EFLAGS, this means that it is setting that value. In which case there can be instructions further down the line which use EFLAGS (they use the EFLAGS from the CMOV_GR*, right?).

To avoid further confusion, could you give an example of where you think it shouldn't be marked as live-in? (You can use 'llc -print-machineinstrs ...' to get the machine instruction dump.)

-bw

> -----Original Message-----
> From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] 
> Sent: Friday, June 03, 2011 3:53 AM
> To: Bill Wendling
> Cc: Galanov, Sergey; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] MachineSink and EFLAGS
> 
> 
> On Jun 2, 2011, at 12:58 PM, Bill Wendling wrote:
> 
>> On Jun 2, 2011, at 3:53 AM, Galanov, Sergey wrote:
>> 
>>> Hi Bill.
>>> 
>>> Thank you very much! Now I see my understanding was incorrect :) A dependence from a single physreg-defining instruction (like CMP or TEST) is allowed to be shared in several instructions unless that register is not clobbered (and this is what we have with CMOV_FR64). Wouldn't it be safe then to not set the live-in flag in EmitLoweredSelect for instructions which are marked as defining EFLAGS (like the integer pseudo cmovs)?
>>> 
>> Hi Sergey,
>> 
>> I'm not certain what that would buy us. If I understand your suggestion correctly, not setting the EFLAGS as live-in to a basic block would mean that we'd have to execute the instruction to reset the EFLAGS register, right? That would mean more code, longer live ranges, etc.
> 
> To clarify, a physical register may be defined in one basic block and used in another. In that case, it must be marked as live-in in all basic blocks entered on any path between the def and the use.
> 
> This is effectively manual register allocation, and it should be avoided. It is necessary sometimes, though. Like in select lowering.
> 
> The machine code verifier has good checks for this. If it complains about missing live-in registers, miscompilations are possible.
> 
> /jakob
> 
> 
> --------------------------------------------------------------------
> Closed Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park, 
> 17 Krylatskaya Str., Bldg 4, Moscow 121614, 
> Russian Federation
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 


--------------------------------------------------------------------
Closed Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park, 
17 Krylatskaya Str., Bldg 4, Moscow 121614, 
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.