------- Comment #24 from dberlin at gcc dot gnu dot org 2008-10-15 18:50
-------
Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
On Wed, Oct 15, 2008 at 2:43 PM, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
>
>
> ------- Comment #23 from rguenther at suse dot de 2008-10-15 18:43 -------
> Subject: Re: [4.4 Regression] calculix gets
> wrong answer for -O1 -ffast-math
>
> On Wed, 15 Oct 2008, rguenther at suse dot de wrote:
>
>> ------- Comment #22 from rguenther at suse dot de 2008-10-15 18:33 -------
>> Subject: Re: [4.4 Regression] calculix gets
>> wrong answer for -O1 -ffast-math
>>
>> On Wed, 15 Oct 2008, dberlin at dberlin dot org wrote:
>>
>> > ------- Comment #21 from dberlin at gcc dot gnu dot org 2008-10-15 17:55
>> > -------
>> > Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1
>> > -ffast-math
>> >
>> > >
>> > > It already does (I fixed that recently), but we only phi-translate during
>> > > insertion and we
>> > > don't insert for that case, as obviously there is no partial redundancy.
>> >
>> > True, but if it discovered all the new phi arguments would be constant
>> > it used to create a new phi node with the new constant values and let
>> > eliminate replace the old calculation with the new phi node.
>> >
>> > Maybe it only did this if all the constants ended up the same value,
>> > but it would be trivial to do it if all the arguments are constant,
>> > regardless of whether they are the same value.
>> > :)
>>
>> Well, we already do for
>>
>> int foo (int b)
>> {
>> double i;
>> if (b)
>> i = 4;
>> else
>> i = 9;
>> return __builtin_sqrt(i);
>> }
>>
>> <bb 4>:
>> # i_1 = PHI <4.0e+0(5), 9.0e+0(3)>
>> # prephitmp.11_7 = PHI <2.0e+0(5), 3.0e+0(3)>
>> # prephitmp.12_8 = PHI <2(5), 3(3)>
>> D.1238_5 = prephitmp.11_7;
>> D.1237_6 = prephitmp.12_8;
>> return D.1237_6;
>
> Ok, for return __builtin_pow (i, i) it doesn't work because we
> do not register phi-translations that result in constants (translating
> i does) and then we run into the if (seen) guard and fail to
> phi-translate.
>
> Either we should register phi-translations for them
We should be.
REmember we used to always create names for constants, and then we
removed that because the constants were valid arguments for GIMPLE
expressions anyway.
Now that we don't always produce NAME, we should be allowing
registration of translations that result in CONSTANT.
Otherwise we will also miss partial redundancies where one phi
arguments evaluates to constant, as well, because when it comes time
to look it up, it will come up with no translation, and we will assume
it's nnot partially redundant.
--Dan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
