[PATCH] [PATCH] PR rtl-optimization/96791 Check precision of partial modes

Segher Boessenkool segher@kernel.crashing.org
Fri Sep 11 14:16:23 GMT 2020


On Fri, Sep 11, 2020 at 08:07:39AM +0200, Richard Biener wrote:
> On Thu, Sep 10, 2020 at 5:12 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Thu, Sep 10, 2020 at 04:33:30PM +0200, Richard Biener wrote:
> > > On Thu, Sep 10, 2020 at 4:22 PM Aaron Sawdey <acsawdey@linux.ibm.com> wrote:
> > > > If it feels like a hack, that would because it is a hack.
> > > >
> > > > What I’d really like to discuss is how to accomplish the real goal: keep anything from trying to do other operations (zero/sign extend for one) to POImode.
> > > >
> > > > Is there an existing mechanism for this?
> > >
> > > Not that I know, but somehow x86 gets away with OImode and XImode without
> > > providing too many patterns for those.
> >
> > What we were seeing is DSE (of all things!) tries to extract a DImode
> > from a POImode (and expects that insn to exist!)  That is no good.
> 
> Maybe.  I don't know what kind of operations have to exist if a mode
> is present and what not.
> But are you sure this will be the only case you'll run into?

No, I am not sure if there are bugs related to this elsewhere in the
compiler :-)

Until 2014 (and documented just days ago ;-) ) all bits of a partial
integer mode were considered unknown.  I have looked at a lot of it in
our code the past weeks, and we still treat it like that in most places.

We now see bootstrap problems if we use POImode in some contexts (that's
this PR96791).  POImode can only live in pairs of VSX registers; taking
a subreg of POImode that would not be valid on one VSX register is not
okay.

Maybe we are missing some hooks or macros?


Segher


More information about the Gcc-patches mailing list