This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR target/85358: Add target hook to prevent default widening
- From: Richard Biener <rguenther at suse dot de>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>,Michael Meissner <meissner at linux dot ibm dot com>,GCC Patches <gcc-patches at gcc dot gnu dot org>,David Edelsohn <dje dot gcc at gmail dot com>,Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>,François Dumont <fdumont at gcc dot gnu dot org>,Jeff Law <law at redhat dot com>,Eric Botcazou <ebotcazou at libertysurf dot fr>,Joseph Myers <joseph at codesourcery dot com>,Jakub Jelinek <jakub at redhat dot com>
- Date: Tue, 05 Jun 2018 19:27:33 +0200
- Subject: Re: [PATCH] PR target/85358: Add target hook to prevent default widening
- References: <20180522232416.GA20583@ibm-toto.the-meissners.org> <20180601203654.GA5543@ibm-toto.the-meissners.org> <20180605165022.GG17342@gate.crashing.org>
On June 5, 2018 6:50:22 PM GMT+02:00, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>On Fri, Jun 01, 2018 at 04:36:54PM -0400, Michael Meissner wrote:
>> As I mentioned previously, the initialization process needs to go
>through all
>> of the widening tables in order to initialize all FP types, so we
>can't just
>> arbitrarily eliminate IFmode from the widening table.
>
>Or change the initialisation process. There is no wider mode for
>IFmode,
>and IFmode can not be used as a wider mode for any other mode.
>
>> I could imagine having an alternative *_FLOAT_MODE that essentially
>marks which
>> modes shouldn't be widened to/from and binop/unop could use. Or I
>could
>> imagine making two widening tables, one for initialization, and one
>for
>> binop/unop, or other possibilities.
>
>For integer types there are the partial int types, maybe we want
>something
>similar for float?
Are there other targets with similar kind of (FP) modes or is ppc the only one with this 'legacy'? Also keep in mind that you intended to backport this...
Why not simply make IBM and IEEE double mutually exclusive inside a TU?
Richard.
>
>Segher