On 10/15/19 4:32 AM, Richard Biener wrote: > 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.
First off, there's nothing special about VSX/non-VSX here, so when I talk about VSX below, I'm really just using it as a stand-in for any option. So what you're saying is that a VSX enabled function that calls a non-VSX enabled function should be able to inline that non-VSX function. That is what the current code allows and I agree that should still be allowed. My extra code only disallows that scenario *IF* the user explicitly said DO NOT compile the callee function with VSX. It still allows it to be inlined if the callee was compiled without VSX implicitly / by default, so I don't think my patch disallows the scenario you mention above. If the user explicitly said not to compile a function with a particular option, how can we justify ignoring that request just because we're inlining it? We don't do that for the out of line version of that callee function. > How can it be fatal to inline a non-VSX function into a VSX one? I can think of scenarios where it could be fatal (again, VSX is just a stand-in for any option), but maybe the user used -mno-vsx for performance reasons or maybe this is kernel code and the user knows this function will be run with VSX hardware disabled or ... Peter
