------- Comment #25 from dberlin at gcc dot gnu dot org 2008-10-16 23:30
-------
Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
I fixed the PRE issue with builtin_pow here.
:)
On Wed, Oct 15, 2008 at 2:50 PM, dberlin at dberlin dot org
<[EMAIL PROTECTED]> wrote:
>
>
> ------- 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
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
