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: Michael Meissner <meissner at linux dot ibm dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Michael Meissner <meissner at linux dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing 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>, Jakub Jelinek <jakub at redhat dot com>
- Date: Mon, 4 Jun 2018 13:16:11 -0400
- 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> <alpine.DEB.2.20.1806012236580.25633@digraph.polyomino.org.uk> <alpine.LSU.2.20.1806040843060.24704@zhemvz.fhfr.qr>
On Mon, Jun 04, 2018 at 08:46:42AM +0200, Richard Biener wrote:
> On Fri, 1 Jun 2018, Joseph Myers wrote:
>
> > On Fri, 1 Jun 2018, Michael Meissner wrote:
> >
> > > I'm wondering if there are other suggestions to make this patch acceptable.
> > >
> > > 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.
> >
> > Initialization that's meant to cover all floating-point modes logically
> > should not rely on everything being reachable by the "wider" relation.
> >
> > That is, I'd expect it to do something equivalent to
> > FOR_EACH_MODE_IN_CLASS (mode, MODE_FLOAT) rather than something based on
> > "wider".
>
> The unfortunate thing is that all iterators are wrapped around
> the "wider" relationship - we do not have any other way to find
> related modes. So the concept that all modes in a class can be
> ordered after their width is baked in very deeply. That's IMHO
> something we need to eventually fix to avoid this kind of
> target-hook "hacks".
>
> Richard.
Given the related modes are in sequential order now, I could imagine ways to do
the initialization and iterators using those values.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797