This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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))
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Tamar Christina <Tamar dot Christina at arm dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 Aug 2019 22:03:53 +0000
- Subject: 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))
- Ironport-sdr: mKgAaD1qbWHzeDZeC/qiKLXyzkPjFlcAkvqhu6/60kbT5g8ADKq2g5UPTcEC6X/JB6sJSrvxgn k1JCpmJj20jnKKnnF1mVsA8PZcDLcySO+yJChaab52KL/ZGNuHoD+ETvr0X5aUBQql/5E6DX9N nt6E2gcF6F07N1GJeWgP352e0FpMLwnMhLc5b89qoU/L74RIBj/BnUaMFBZxHIBiOeJGZGpK8Y nBzL2PLT36G8LSpTFl7jouTKlhl+R/H+hCjw4X/2T5Bk5f0oqn03yUAiniUHi56CQD/I3iTzxg Ias=
- Ironport-sdr: YgeE/en5VIBW+mvIOV8xp/VL4QSogj3GujJAx9fI9QwrdKeroBcgqiBMhwmJxvYr0PFI7c/gMH 7DUzFHcz9XIJgvuodoic8lemKQP+SzXwXPjhhHPa0EiFY3sY8aojuMCocsR0OF8yFFlstvyZDv /J1RgyY6Yb9bY8/e6LyWPqp/DaUrTr+mK9gJCEguqrhEz68+2/giqgVhEK2L5IadNBpn9Dzd40 qec68YRuCslTEd1rvCH2suEcRhNNEJ8sgvxtVW030D0P2dZbxCJCqVwzNKPM8bQJ/bLPrNY9bE 0nk=
- References: <20190625083126.GA19632@arm.com> <DB6PR0802MB230918BEA271728437E6CA57FFE30@DB6PR0802MB2309.eurprd08.prod.outlook.com> <alpine.LSU.2.20.1906251044350.10704@zhemvz.fhfr.qr> <20190702094115.GA22370@arm.com> <alpine.LSU.2.20.1907021214070.2976@zhemvz.fhfr.qr> <20190702164351.GA12197@arm.com> <20190730070911.GH15878@tucnak>
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
joseph@codesourcery.com