svn commit: r253802 - head/contrib/llvm/tools/clang/lib/Headers

Dimitry Andric dim at freebsd.org
Tue Jul 30 14:17:00 UTC 2013


On Jul 30, 2013, at 16:09, Matthew Fleming <mdf at freebsd.org> wrote:
> On Tue, Jul 30, 2013 at 5:33 AM, Dimitry Andric <dim at freebsd.org> wrote:
> Author: dim
> Date: Tue Jul 30 12:33:21 2013
> New Revision: 253802
> URL: http://svnweb.freebsd.org/changeset/base/253802
> 
> Log:
>   Pull in r186696 from upstream clang trunk:
> 
>     This patch implements __get_cpuid_max() as an inline and __cpuid()
>     and __cpuid_count() as macros to be compatible with GCC's cpuid.h.
>     It also adds bit_<foo> constants for the various feature bits as
>     described in version 039 (May 2011) of Intel's SDM Volume 2 in the
>     description of the CPUID instruction.  The list of bit_<foo>
>     constants is a bit exhaustive (GCC doesn't do near this many).  More
>     bits could be added from a newer version of SDM if desired.
...
> +/* PIC on i386 uses %ebx, so preserve it. */
> +#if __i386__
> +#define __cpuid(__level, __eax, __ebx, __ecx, __edx) \
> +    __asm("  pushl  %%ebx\n" \
> +          "  cpuid\n" \
> +          "  mov    %%ebx,%1\n" \
> +          "  popl   %%ebx" \
...
> PIC mode on amd64 also uses %ebx.  The difference is that FreeBSD makefiles set -fPIC for i386 kernel compile but not amd64.  Locally we use -fPIC for amd64 (it was added 6 years ago to our environment because it gave better kernel debugging).
> 
> Anyways, is there some way to detect PIC mode and use that to decide whether to use %ebx for the cpuid instruction, rather than using i386?

Upstream gcc checks this with:

#if defined(__i386__) && defined(__PIC__)
...
#elif defined(__x86_64__) && (defined(__code_model_medium__) || defined(__code_model_large__)) && defined(__PIC__)
...

and it exchanges ebx or rbx with %k1 or %q1, respectively, instead of push/pop.  That might be a little more efficient.

I guess the defined(__PIC__) should be enough for us, in most cases.  The code_model stuff is for x32 support, which we do not have yet.

-Dimitry



More information about the svn-src-head mailing list