On Thu, Aug 27, 2020 at 4:45 PM H.J. Lu <hjl.to...@gmail.com> wrote:
> > > > > > How about target("baseline-isas-only")? All CPUID functions are
> > > > > > inlined.
> > > > >
> > > > > No, I don't think this is a good idea. Now consider the situation that
> > > > > caller functions are compiled with e.g. -mgeneral-regs-only. Due to
> > > > > #pragmas, CPUID functions are compiled with a superset ISAs, so they
> > > > > again won't be inlined. ISAs of caller functions and CPUID should
> > > > > match, the best way is to include <cpuid.h> after the #pragma. And
> > > > > IMO, general-regs-only target #pragma is an excellent setting for
> > > > > both: cpuid.h and caller bit testing functions.
> > > > >
> > > > > So, if we care about inlining, decorating cpuid.h with target pragmas
> > > > > is a bad idea.
> > > >
> > > > This can be done with #pragma in <cpuid.h>.
> > > >
> > >
> > > We just need to update ix86_can_inline_p to allow inline functions
> > > with baseline-isas-only and general-regs-only attributes if caller
> > > supports the same set of ISAs.
> > >
> > > Here is the updated patch.
> >
> > I'm not against it, but I don't plan to approve the attached patch.
> >
>
> How about this one?
I really don't see any benefit in introducing baseline-isas-only
#pragma, when we have general-regs-only #pragma. We may want (for
whatever reason) to avoid SSE2 movd/movq instructions also for 64bit
targets in functions that test bits, returned by cpuid. And since
cpuid.h functions are extremely simple (because we want them to be
inlined!), we can simply #include them after mentioned #pragma,
together with bit testing functions. This way, all problems involving
inlining are avoided.
Uros.
