On Tue, Oct 15, 2019 at 01:19:51PM +0200, Richard Biener wrote: > On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool > <seg...@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
