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? > > 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. Richard. > > Segher
