Re: eflags anomaly (was: Re: [Valgrind-developers] lazy eflags seems to work now)

[Jeremy F. <je...@go...>]

On Fri, 2002-12-06 at 14:37, Julian Seward wrote:

> The translation is pretty dismal, due to calling helpers for both fnstsw and
> sahf, but "that's not important right now" :)  The problem is the call the to
> latter's helper ... and specifically the add $0x4,%esp to clear the args off
> the stack.  This trashes the live %eflags

Ah, yes, that's where I've seen moz spin.  That's why I was suspecting
some badness in FP+flags interaction.

> Assuming this analysis is correct ... there's no convenient way to clear
> dead args off the real stack, unless we find a dead reg to dump it in.

Ewww, nasty.

> Umm, actually that's nonsense.  Imagine we have a baseBlock slot purely
> for the purpose of receiving deal values, then we could do
> 
>    popl VGOFF_(dummySlot)(%ebp)
> 
> Just occasionally, CISC is great!
> 
> What do you think?  Is the analysis correct?  

Yes, that looks likely.  The quick fix is to change the
VG_(new_emit)(True, ...) to False in emit_add_lit_to_esp, since that add
is not operating on Simd state.  That will make it generate flag save
before trashing them.  I agree the nicer solution is to fix the helper
calling convention to not trash the flags.  How about changing the
convention to just use a real register for the value?  Unfortunately for
helpers like CPUID, the stack does seem like the nicest way of doing the
passing (unless you want to allocate an array of slots in the bas
block).

It's a pity that SAHF/LAHF doesn't do the O flag; otherwise they'd be
ideal for flags saving/restoring - the P3 optim guide says they're 1
uop.

        J