On 24/06/11 09:28, Richard Guenther wrote:
>> > To be clear, it only skips past NOP_EXPR. Is it not the case that what
>> > you're describing would need a CONVERT_EXPR?
> NOP_EXPR is the same as CONVERT_EXPR.
Are you sure?
I thought this was safe because the internals manual says:
NOP_EXPR
These nodes are used to represent conversions that do not require any
code-generation ....
CONVERT_EXPR
These nodes are similar to NOP_EXPRs, but are used in those
situations where code may need to be generated ....
So, I tried this example:
int
foo (int a, short b, short c)
{
int bc = b * c;
return a + (short)bc;
}
Both before and after my patch, GCC gives:
mul r2, r1, r2
sxtah r0, r0, r2
(where, SXTAH means sign-extend the third operand from HImode to SImode
and add to the second operand.)
The dump after the widening_mult pass is:
foo (int a, short int b, short int c)
{
int bc;
int D.2018;
short int D.2017;
int D.2016;
int D.2015;
int D.2014;
<bb 2>:
D.2014_2 = (int) b_1(D);
D.2015_4 = (int) c_3(D);
bc_5 = b_1(D) w* c_3(D);
D.2017_6 = (short int) bc_5;
D.2018_7 = (int) D.2017_6;
D.2016_9 = D.2018_7 + a_8(D);
return D.2016_9;
}
Where you can clearly see that the addition has not been recognised as a
multiply-and-accumulate.
When I step through convert_plusminus_to_widen, I can see that the
reason it has not matched is because "D.2017_6 = (short int) bc_5" is
encoded with a CONVERT_EXPR, just as the manual said it would be.
So, according to the manual, and my (admittedly limited) experiments,
skipping over NOP_EXPR does appear to be safe.
But you say that it isn't safe. So now I'm confused. :(
I can certainly add checks to make sure that the skipped operations
actually don't make any important changes to the value, but do I need to?
Andrew
