[PATCH] rs6000: -flto forgets 'no-vsx' function attributes (PR target/70010)

[Segher Boessenkool]

On Tue, Oct 15, 2019 at 01:19:51PM +0200, Richard Biener wrote:
> On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > > > I think we just need to fix the bug in the current logic when checking
> > > > whether the caller's ISA flags supports the callee's ISA flags. ...and
> > > > for that, I think we just need to add a test that enforces that the
> > > > caller's ISA flags match exactly the callee's flags, for those flags
> > > > that were explicitly set in the callee.  The patch below seems to fix
> > > > the issue (regtesting now).  Does this look like what we want?
> > >
> > > I believe this is going to bite you exactly in the case you want the
> > > opposite behavior.  If you have CUs compiled with defaults and
> > > a specialized one with VSX that calls into generic compiled functions
> > > you _do_ want to allow inlining into the VSX enabled routines.
> >
> > Yes, but *not* inlining is relatively harmless, while inlining can be
> > fatal.  I don't see how we can handle both scenarios optimally.
> 
> How can it be fatal to inline a non-VSX function into a VSX one?

Oh I misread, I thought it was the other way around.

> > > Just
> > > think of LTO, C++ and comdats - you'll get a random comdat entity
> > > at link time for inlining - either from the VSX CU or the non-VSX one.
> >
> > This would make LTO totally unusable, with or without this patch?  Something
> > else must be going on?
> 
> It's the same without LTO - the linker will simply choose (randomly)
> one of the comdats from one of the CUs providing it, not caring about
> some built with and some without VSX.

Hrm, so how does that ever work?


Segher