|
From: Florian K. <br...@ac...> - 2012-12-21 15:22:58
|
On 12/19/2012 11:26 AM, John Reiser wrote:
>> New Revision: 2598
>>
>> Log:
>> Constant folder: enable Sub32(x,0) ==> x.
>
> Beware. Processor status (flag bits) might change, and in "unexpected" ways.
>
> PowerPC implements SUB(x, y) as ADDwithCarry(x, ~y, 1),
Interesting. s390 does this, too.
> and does not invert the Carry bit when the original opcode was SUB.
> So, subtracting zero always sets Carry (if status is being recorded.)
>
> On x86 SUB records a Borrow in the C status bit, so subtracting zero
> always clears the C bit.
>
True, but I think this optimisation does not break break anything.
For these reasons:
(1) Performing the optimisation is completely safe when the flags bits
for this subtraction are not examined, as in (x - 0) + y.
For arithmetic operations that are generated during IR generation
(e.g. for address computation) the flag bits are not examined.
(2) From #1 it follows that this optimisation could only make a
difference if
(a) it was written in the source code
(b) it was preserved through the compiler optimisation
(c) the carry bit is tested on the result
While not impossible that looks like a scenario that is quite
unlikely to occur. Probably requires some handwritten assembly.
(3) Even if IR optimisation replaces SUB(x,0) -> x that does not mean
that the flags are computed improperly. Condition code computation
in VEX is performed by putting the operands of an operation into the
flags thunk (guest state) together with a tag that describes the
operation that is to be performed on them. Here, something like:
[SUB32, x, 0]
If it turns out that flags bits are needed, the thunk will be
evaluated. So, if there is a problem here at all, it would imply
that the code that evaluates the flags thunk is incorrect.
If you're interested take a look at function s390_calculate_cc
in guest_s390_helpers.c that does exactly this.
No reason for concern.
Florian
|