List Info

Thread: undocumented -march=x86-64 option in gcc 4.1




undocumented -march=x86-64 option in gcc 4.1
user name
2007-04-08 21:22:22
There is an [undocumented] 'x86-64' architecture type in gcc
4.1 which
_apparently_ generates instructions common to AMD64 and
EMT64.  I'm
looking into this further to make sure that this is indeed
the case.
If it is, then it is my position that:

-- we should patch the gcc(1) manual page to reflect this

-- NetBSD/amd64 builds should use this by default.

Comments?

Regards,

--Blair

-- 
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>


"The frivolity and boredom which unsettle the
established order, the
vague foreboding of something unknown, these are the heralds
of
approaching change.  The gradual crumbling that left
unaltered the
face of the whole is cut short by a sunburst which, in one
flash,
illuminates the features of the new world."  --G.W.F.
Hegel,
_Phenomenology of Spirit_ 5:11

Re: undocumented -march=x86-64 option in gcc 4.1
user name
2007-04-09 08:25:31
I agree that it isn't our job.  I explicitly stated that we
should
only be interested in this if it turned out that it indeed
does what I
think it does.  Certainly, if it hurts more than it helps,
why use it?

My experience thusfar--for what it's worth, which isn't much
of any
probative value--is that -march=nocona AND gcc 4.1/NetBSD's
default
are significantly worse than -march=x86-64.  I switched to
the i386
port in part to get DRI, but mostly because the performance
of my
machine (A Pentium D 930/Intel D945GTP motherboard) was
HORRID using
the amd64 port.  One needed no benchmarks to see how much
slower it
was in many cases.  I'm still researching this amidst a
paucity of
information, but I've garnered thusfar that -march=nocona
may actually
disable the instruction scheduler.  Moreover, there are bug
reports of
gcc ( both 4.0 and 4.1) generating 3dnow prefetch
instructions by
default on x86_64.

My point here is that such a flag isn't necessarily a no-op
at all: it
tells the compiler only to use instructions which AMD and
Intel
processors *have in common*.  In fact, gcc 4.2 and above DO
have this
feature documented, although it is -march=generic.

Disparate instruction sets are even more of a problem for
the Core 2 chips, etc.

I only have an EMT64 processor because I got it through a
dealer I did
some work for at a great price, and the intel board has a
3-year parts
and labor warranty.  Barring these circumstances, I would've
simply
bought an AMD CPU and saved myself the headache, as AMD is
clearly the
better choice here, IMHO.

I'm also interested in -march=x86-64 because there are
severe linux
compatability problems on NetBSD/amd64 _ONLY_ with Intel
chips.

Again, I agree with the general spirit of your message.  The
choices I
have with gcc 4.1, though, are like the US presidential
elections as
of late: I'd go with a third party just to avoid the
complications of
the other two. ;)

I rebuilt my whole tree and kernel with -march=x86_64 and
now my usual
workloads seem a lot more on par with i386.  This could be
a
confirmation bias of mine, though, so I'll have to run
benchmarks at
some point.

Regards,

--Blair




-- 
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>


"The frivolity and boredom which unsettle the
established order, the
vague foreboding of something unknown, these are the heralds
of
approaching change.  The gradual crumbling that left
unaltered the
face of the whole is cut short by a sunburst which, in one
flash,
illuminates the features of the new world."  --G.W.F.
Hegel,
_Phenomenology of Spirit_ 5:11

Re: undocumented -march=x86-64 option in gcc 4.1
user name
2007-04-09 16:38:56
Take a look at the header and .md files for gcc4 in our
tree.  I don't
recall where it is offhand exactly, but the default for
x86-64 (at
least on NetBSD) is march=k8.

Things should improve somewhat whenever we get gcc 4.2,
which should
do the "Right Thing"(tm).


--Blair

-- 
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>


"The frivolity and boredom which unsettle the
established order, the
vague foreboding of something unknown, these are the heralds
of
approaching change.  The gradual crumbling that left
unaltered the
face of the whole is cut short by a sunburst which, in one
flash,
illuminates the features of the new world."  --G.W.F.
Hegel,
_Phenomenology of Spirit_ 5:11

Re: undocumented -march=x86-64 option in gcc 4.1
country flaguser name
Netherlands
2007-04-10 04:58:21
Blair Sadewitz wrote:
> There is an [undocumented] 'x86-64' architecture type
in gcc 4.1 which
> _apparently_ generates instructions common to AMD64 and
EMT64.  I'm
> looking into this further to make sure that this is
indeed the case.
> If it is, then it is my position that:
>
> -- we should patch the gcc(1) manual page to reflect
this
>
> -- NetBSD/amd64 builds should use this by default.
>
> Comments?
EMT64 was cloned from amd64, and meant to be compatible.
Now, in a few 
corner cases, Intel didn't make it quite compatible, but
these cases 
were fixed, and the differences left are pretty obscure and
should not 
appear in any kernel code, especially not generated code.

Can you give an example on how incompatible code cold be
generated?

Also, the Linux compat issues you were seeing: I very
strongly doubt 
that they were due to any EMT64/AMD64 differences. Unless
you stumbled 
on an undocumented difference..

- Frank


[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )