This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix up -fexcess-precision handling in LTO (was Re: [GCC][middle-end] Add rules to strip away unneeded type casts in expressions (2nd patch))

On Tue, 30 Jul 2019, Jakub Jelinek wrote:

> Furthermore, some comments claimed that the proper EXCESS_PRECISION_STANDARD
> handling requires FE support, but that also doesn't seem to be the case
> these days, some FEs even just use EXCESS_PRECISION_STANDARD by default
> (go, D).
> So, the following patch gets rid of flag_excess_precision and renames
> flag_excess_precision_cmdline to flag_excess_precision, plus adds
> Optimization flag to that command line option, so that we remember it during
> compilation and e.g. during LTO can then have some functions with standard
> excess precision and others with fast excess precision.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK minus the removal of the comment in lhd_post_options.  Proper handling 
requires front-end support (to generate GIMPLE with the operations in the 
intended type).  Back-end support (to avoid having insn patterns claiming 
to operate on the types the processor in fact does not have direct support 
for arithmetic on), although not strictly required, is a very good idea, 
to make it more obvious if something is wrongly generating arithmetic on 
inappropriate types.  And then you need the middle-end support (to avoid 
transformations introducing operations in the types that aren't meant to 
have direct operations, even if in fact the semantics are equivalent) as 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]