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 well. -- Joseph S. Myers jos...@codesourcery.com
