[LLVMdev] MachineSink and EFLAGS

[Bill Wendling]

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.
>