mcpu versus xtarget (GCC for SPARC Systems)
Does anyone know the relationship between the "mcpu" and "xtarget" params in gccfss, specifically what happens when they are in conflict?
The "mcpu" param is the normal way in traditional GCC to set the instruction/register set and instruction scheduling options for SPARC code generation - for UltraSPARC implementations this usually means "mcpu=ultrasparc" or "mcpu=ultrasparc3". By default (even in gccfss), the default is "v7" (SPARC v7 arch).
According to the docs, in gccfss the "xtarget" param appears to be the preferred way to set instruction/etc. options and supposedly defaults to "generic", even though on my Ultra IIi-based system (that is, "2i") it's expanding the default to include "xchip=ultra3"!
This means the first phase is generating SPARC v7 code whilst later phases are defaulting to Ultra III code (and the final executable claims to be a v8plus binary).
All very confusing!
Does this mean to keep all phases of compile/optimise/link in check, one should use _both_ "mcpu" and "xtarget" with gccfss? If not, then what is the relationship between the two (especially given the above situation when they conflict)? Couldn't "mcpu" just be set to control "xtarget" (or vice versa) so only one needs to be set? Obviously for GCC compatibility this preferrably would be "mcpu".
Surely I'm not the only one concerned about this conflict...
[1410 byte] By [
d.b] at [2007-11-25 23:11:40]
# 1
The gcc4ss default is actually v8plus (it's in docs), not v7.
You probably noticed that -mcpu=v7 is passed to cc1 component ofgcc4ss, but that flag doesn't control code generation in backend.
-mcpu flags are mapped to their -xarch equivalents. So they only set target instruction set architecture. Also -mcpu flags are ignored when -xarch flags are given.
-xtarget flag is used as a convenience to set -xchip, -xarch, -xcache at the same time and, yes, -xtarget flag is preferred way to tune for specific chip.
In your case just adding -xtarget=ultra2i should be enough.
I hope that clarifies it.
# 2
Think of -mcpu and -xtarget as "macros' that expand to -xchip, -xarch, and, possibly, -xcache with appropriate values. The value of the last (rightmost) -xchip is the value of -xchip used. Similary for -xarch and -xcache.
I would recommend for sanity reasons that you use only one of -mcpu or -xtarget. Which one you use is your choice.
The driver to gccfss keeps the two options straight between the various phases so you don't have to specify both -mcpu and -xtarget.
Ross at 2007-7-5 18:01:39 >
# 3
Thanks for the comments guys, but unfortunately the documentation, your responses and the behaviour from the compiler aren't entirely matching - hence my confusion. I'll try to explain things better this time...
If you specify _neither_ mcpu nor xtarget, you would expect default behaviour; according to the docs, the default for "mcpu" is "v7" (this is confirmed with "gcc -v" output) whilst the default for "xtarget" is "generic" which according to the docs should produce "-xarch=generic -xchip=generic -xcache=generic". Separately the gccfss docs say that the defaults for the xarch, xchip and xcache options are in fact: "-xarch=v8plus -xchip=generic -xcache=generic" - so straight away the docs are internally inconsistent (that's after you ignore the fact that the defaults for the GCC-style option are for a different architecture than the defaults of the GCCFSS-style options).
Okay, so if I accept the defaults are really to target the v8plus architecture (not v7) and that the "mcpu=v7" I'm seeing in "gcc -v" output (without using either mcpu or any of the x-options) is really irrelevant, then why in that same "gcc -v" output (remember, with _no_ mcpu, mtune, xarch, xcache or xtarget options specified) on my ultra2i platform does the output clearly contain calls to the backend processes (iropt and cg) using the options:
-xarch=generic -xchip=ultra3 -xcache=generic
Huh?! If "mcpu" just "mapped to their xarch equivalents" and that "the driver to gccfss keeps the two options straight" then I should be able to just specify _either_ mcpu or xtarget and the compilation phases would be consistent in their option usage - but the reality is that the defaults don't match the docs, the docs are internally inconsistent and if I (for example) just specify "mcpu" expecting "the driver to ... [keep] the two options straight", only the initial (cc1) phase appears to pay any real attention to the mcpu option - later phases (iropt and cg) may be in a small way influenced but they (for the most part) ignore mcpu and go off on their own tangent.
At the very least, shouldn't the docs be made internally consistent and mcpu's default changed to match that of the other options?
If I use "xtarget=ultra2i" then in phases iropt and cg I get the xarch, xchip and xcache expansions I would expect, but cc1 still uses its own default of "mcpu=v7", which indicates that the interaction between mcpu and the x-options isn't as clear cut as it should be (or at least, the value/purpose of "mcpu" in GCCFSS is not the same as that of regular GCC).
Does that make the problem any clearer? :-)
Thanks..
db at 2007-7-5 18:01:39 >
# 4
The -mxpu/-mtune/-xtarget stuff is being redone for the next release. The proposed handling is described in cooltools.sunsource.net/gcc/mcpu.html.
The values of -mcpu/-mtune that are passed to cc1 are ignored by cc1 since we exit cc1 before those values are used in any compilation decision.
The default use of -xchip=ultra3 was a workaround for a bug that was fixed before release but we forgot to remove the workaround. That will be corrected in the next release.
Ross at 2007-7-5 18:01:39 >
# 5
Thanks, that clears some of the confusion. Looking forward to the next release.
db at 2007-7-5 18:01:39 >
