This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: mutex in frame code



> >>>>> Richard Henderson writes:
> 
> Richard> If we commonize on anything, I think it should be `arch' and `tune';
> Richard> `cpu' is too ambiguous.
> 
> 	I repeat again that -march= provides the wrong information for the
> PowerPC port.  One wants a simple way to specify both architecture and
> scheduler tuning; -mcpu= provides that information.

The ability to have two flags is important only when the user is
distributing binaries that must work on multiple variants of the same
architecture.

Consider architectures to be sets (there are multiple implementations of
a given architecture).  With -mtune you specify that you want to tune for
one member of the set, with -march you would specify the set.  If there
is only one possible set that a member can belong to (evidently the case
for the PowerPC port), the user would only need to give the -mtune flag,
and the -mcpu flag can be a synonym.  Consequence: no change for the
PowerPC port, except maybe accepting a synonym for the flag to make things
more consistent.

I was under the impression that there are really three sets for the
Power/PowerPC port: POWER machines, PowerPC machines, and common, where
we want to produce code that runs on either.  You're the expert, if you
say there is no reason for "common" I'll take your word for it.
But at least conceptually it seems I could say to tune for some processor
but generate common code.

>  -march= primarily is
> useful for processors in which each chip extended the architecture like
> x86 and Alpha, not for processors where an ISA was designed and maintained
> like PowerPC.

If so, we can at least discuss how to use it consistently.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]