[PATCH] Add PAREN_EXPR

[Tim Prince]

Richard Guenther wrote:
> On Wed, 20 Feb 2008, Tim Prince wrote:
> 
>> Richard Guenther wrote:
>>> On Tue, 19 Feb 2008, Tobias Burnus wrote:
>>>
>>>> FX wrote:
>>>>>>         * trans-expr.c (gfc_conv_expr_op): Expand INTRINSIC_PARENTHESES
>>>>>>         as unary PAREN_EXPR for real and complex typed expressions.
>>>>>>         * options.c (gfc_init_options): Enable flag_associative_math if
>>>>>>         it isn't disabled automatically.
>>>>>>
>>>>>>         * gfortran.dg/reassoc_1.f90: New testcase.
>>>>>>         * gfortran.dg/reassoc_2.f90: Likewise.
>>>>>>     
>>>>> Fortran part is OK. Thanks!
>>>>>   
>>>> Thanks also from me. Is it possible to add a flag for disabling the
>>>> PAREN_EXPR? I'm sure some users want to have this to gain some speed. (For
>>>> a/(b*c) the () are often only used because it is easier to read than a/b/c;
>>>> for such programs it might be useful to be able to disable it.)
>>>>
>> How would the version with 2 divisions become faster than the original?
>> It seems more likely that the original version would have been written for
>> improved speed, or to avoid inconsistencies according to whether the
>> version with 2 divides is optimized.
> 
> Yeah.  It's probably more for things like a-(b+c) where it doesn't matter
> to use the equivalent a-b-c.  Or other cases where parens are added
> for syntactic reasons rather than to guard against re-association.
Silent re-association of addition has broken many applications.  It became
 popular in some circles in the time when all i386 machines used extended
precision, and it was more often true that "it didn't matter."
I would see some advantage in provision of an option to permit -ffast-math
without re-association in violation of language standards.  For example,
the optimizations on division which are reserved for -ffast-math could be
used more often, if they were not coupled with violation of parentheses.

> 
> That said - somebody with decent knowledge of the Fortran standard
> (and its user community) should decide what to do by default and
> what to do with -ffast-math and if Fortran wants an extra flag
> that says it wants full IEEE compatibility.
Fortran experts already have contributed expertise in the way gcc handles
this.  The Fortran standard is clear and has expert experience behind it.
> 
> It might for example be ok to by default do the equivalent of
> -fno-signed-zeros -fno-trapping-math -fassociative-math
IMHO the best use of -fassociative-math is to permit vectorization of sum
reduction.  Such an option, if it does not go so far as to violate Fortran
standard, is a clear benefit.
> 
> I'm not sure about -ffinite-math-only (though it was said Fortran
> doesn't know about NaNs or Infs), as that has the bad side-effect
> of also unconditionally folding of isnan() etc.  Still without
> that flag we do not simplify x - x to 0. or 0. * x to 0., so
> re-association is only useful to combine constants then.
> 
There seems to be some consensus among Fortran compiler developers in
moving toward observance of IEEE behavior as a default, even with normal
optimization, at least to the extent which gfortran does.