On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner <berg...@linux.ibm.com> wrote: >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.
You can probably tell whether there's an explicit -mno-vsx on the command line I wonder how you can tell apart explicit vs. Implicit in the LTO context where the option is represented as target attribute on the 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
