Target processor detection

Target processor detection

[Piotr Wyderski]

I am working on a portable low-level library of atomic operations,
so I need to detect the exact type of the target processor, which is
specified by -mcpu or -march. However, there are two problems.
On a sparc-based platform (Sun Fire 880, Solaris 2.8, 4x UltraSparc III)
this program

#if defined(__arch64__)
    #warning 64-bit architecture
#else
    #warning 32-bit architecture
#endif

#if defined(__sparcv9__) || defined(__sparc_v9__) || defined(__sparcv9)
    #warning Sparc V9
#endif

compiled using GCC 3.4.1

    g++ -mcpu=v9 -mv8plus -mvis -m32 main.cpp

displays only

    #warning 32-bit architecture

with

    g++ -mcpu=v9 -mv8plus -mvis -m64 main.cpp

the result is

    #warning 64-bit architecture
    #warning Sparc V9

Why does __sparc_v9__ depend on the number of bits instead of the -mcpu?
Is this a GCC bug? I've found an e-mail by Jakub Jelinek, which claims, that

"__sparc_v9__ macro is for -mcpu=ultrasparc or -mcpu=v9, which is implied
by -m64, but can be used in 32-bit code as well. __sparc_v9__ means
using v9 instructions, __sparc__ __arch64__ means 64-bit ABI with the
exception of Solaris which uses __sparcv9."

It seems that my interpretation is confirmed by the above text and that it
is
a GCC bug. Could you please clarify the exact meaning of __sparc_v9__?

The second problem is more general. Is it possible to change the meaning
of __i386, __sparc, etc. in the next release of GCC? It should return the
number provided by the user in -mcpu, for example:

    -mcpu=i386 => __i386 = 300
    -mcpu=i486 => __i386 = 400
    -mcpu=i586 => __i386 = 500
    -mcpu=pentiumpro => __i386 = 600
    -mcpu=pentium2 => __i386 = 625
    -mcpu=pentium3 => __i386 = 650
    -mcpu=pentium4 => __i386 = 700

    -mcpu=v8 => __sparc = 800
    -mcpu=v8 -mv8plus => __sparc = 850
    -mcpu=v9 => __sparc = 900
    -mcpu=ultrasparc => __sparc = 1000

and so on. Currently it is just defined to "1", which doesn't help much
if the programmer would like to use something very architecture-specific.
This modification would be backward compatible, because the result of

    #if defined(__i386)

is the same as in the current compiler version.

    Best regards
    Piotr Wyderski








________________________________________________________________________
This email was checked on leaving Microgen for viruses, similar
malicious code and inappropriate content by MessageLabs SkyScan.

DISCLAIMER

This email and any attachments transmitted with it are confidential
and may contain privileged or copyright information. Any views or
opinions expressed in this email are those of the individual sender,
except where the sender specifically states them to be the views of
Microgen.

If you are not the named or intended recipient of this email you
must not read, use or disseminate the information contained within
it for any purpose other than to notify us.  If you have received
this email in error, please notify the sender immediately and
delete this email from your system.

It is your responsibility to protect your system from viruses and
any other harmful code or device, we try to eliminate them from
emails and attachments, but accept no liability for any which remain.
We may monitor or access any or all emails sent to us. 

In the event of technical difficulty with this email, please contact
the sender or it.support@microgen.co.uk

Microgen Information Management Solutions
http://www.microgen.co.uk

Re: Target processor detection

[Jim Wilson]

Piotr Wyderski wrote:
> I am working on a portable low-level library of atomic operations,

Like the existing libatomic-ops package?

> Why does __sparc_v9__ depend on the number of bits instead of the -mcpu?
> Is this a GCC bug? I've found an e-mail by Jakub Jelinek, which claims, that

Jakub was probably describing how it works on linux.  On Solaris, Sun 
sets the standard, and we have to follow Sun's lead here.  It appears 
that the Sun compiler only defines __sparc_v9 for 64-bit compiles, so 
gcc must do so also.  This is done in the gcc/config/sparc/sol2-bi.h 
file which is only used for solaris2.7 and up.  If this assumption about 
the Sun compiler is wrong, then this is a gcc bug.  Otherwise, no.

>     -mcpu=i386 => __i386 = 300

I think this could get confusing very quickly.  What values do we use 
for AMD parts?  What values do we use for PentiumD parts which have 
3-digit part numbers that conflict with this scheme?

This info may also not be accurate enough to be useful in the end. 
Different pentium4 cores have different sets of features.  So just 
knowing that something is a P4 isn't good enough to know what 
instructions exist.  You have to have run time checks to read system 
registers that contain info about what hardware features are present.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: Target processor detection

[Richard Guenther]

On 11/22/05, Jim Wilson <wilson@specifix.com> wrote:
> Piotr Wyderski wrote:
> > I am working on a portable low-level library of atomic operations,
>
> Like the existing libatomic-ops package?
>
> > Why does __sparc_v9__ depend on the number of bits instead of the -mcpu?
> > Is this a GCC bug? I've found an e-mail by Jakub Jelinek, which claims, that
>
> Jakub was probably describing how it works on linux.  On Solaris, Sun
> sets the standard, and we have to follow Sun's lead here.  It appears
> that the Sun compiler only defines __sparc_v9 for 64-bit compiles, so
> gcc must do so also.  This is done in the gcc/config/sparc/sol2-bi.h
> file which is only used for solaris2.7 and up.  If this assumption about
> the Sun compiler is wrong, then this is a gcc bug.  Otherwise, no.
>
> >     -mcpu=i386 => __i386 = 300
>
> I think this could get confusing very quickly.  What values do we use
> for AMD parts?  What values do we use for PentiumD parts which have
> 3-digit part numbers that conflict with this scheme?
>
> This info may also not be accurate enough to be useful in the end.
> Different pentium4 cores have different sets of features.  So just
> knowing that something is a P4 isn't good enough to know what
> instructions exist.  You have to have run time checks to read system
> registers that contain info about what hardware features are present.

Like f.i. as I proposed in
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00965.html
maybe you could comment on that approach.  Sofar the feedback was negative,
so I didn't yet work further on it.

Richard.

> --
> Jim Wilson, GNU Tools Support, http://www.specifix.com
>

Re: Target processor detection

[James E Wilson]

On Tue, 2005-11-22 at 01:53, Richard Guenther wrote:
> Like f.i. as I proposed in
> http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00965.html
> maybe you could comment on that approach.  Sofar the feedback was negative,
> so I didn't yet work further on it.

I fell behind on gcc-patches reading a while ago.  My employer has been
keeping me busy with customer work, which is both good and bad.

Your proposal is more what I was thinking.  It isn't clear how this
solves Piotr Wyderski's problem though.

The main problem I see is that we don't have a good argument for adding
it now.  It is certainly something that would be nice to have, but we
don't actually need it yet.  You can make a more convincing argument if
you have an optimizer pass that uses it.

There is also an issue here of whether we should have builtin functions
or a variable to check.  The single variable solution may run into
trouble later as 32-bits may not be enough for every feature we want to
test.  The extra overhead at startup may annoy some people that don't
care about these features.  Using separate builtin functions adds
overhead though, as then we might end up executing multiple cpuid
instructions, instead of just one in your approach.  It isn't clear
which is the best approach.  If we had optimizer code relying on this
stuff, this might help resolve the issue.

By the way, there is already some related code in
config/i386/crtfastmath.c.  This probably should be updated as part of
your patch.  With your patch, compiling with -ffast-math, we would be
executing two constructors at program startup, both of which are
executing cpuid and parsing its result.  There should be a better way to
do this.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com