This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [PATCH] Pass -mtune and -march options to assembler.


[Returning after a 2 week break]

Mark Mitchell <mark@codesourcery.com> writes:
> Richard Sandiford wrote:
>
>> ...here is that it isn't an "either/or".  Both approaches are only
>> useful if we do them right, and if we do do them right, they're
>> _independently_ useful.
>
> Yes, I think you've made a convincing argument for that.  However, the
> use of specs should be limited to the compilation of .s files, where the
> compiler itself is not involved;

But this is what I disagree with.  I'm not sure whether what you say
is an opinion or a policy.  If it's an opinion, that's fine, let's
agree to disagree.  But if it's a policy, I'd like to explain why
I disagree.

> in the case of compilation (from C source code),
> there's no need for specs, once we posit the existence of
> appropriate directives.

Yes, but the same is equally true the other way round: in the case
of compilation to object files, there's no need for directives if
we have working specs.

As above, let's assume that we're comparing two correct implementations
that the port maintainers are happy with.  Anything else isn't useful.

Your original objections seemed to be that getting specs right was hard,
and that specs were unnecessary when directives are available.  The first
isn't really an issue given the assumption in the last paragraph: if the
port maintainers see a patch they're happy with, any difficulty has been
overcome.  (And remember the original context of this thread.  You were
asking the x86 maintainers to consider rejecting a specs patch even if
it seemed to do what it set out to do.)  As far as the second objection
goes, I think we agree that specs are useful.

So let's go back to three cases that have been talked about:

    (1) gcc BLAH foo.c -o foo.o
    (2) gcc BLAH foo.S
    (3) gcc BLAH foo.c -o foo.s; as foo.s -o foo.o

A correct specs implementation handles (1) and (2).  A correct
directives implementation handles (1) and (3).  What's more, by (my)
definition of correctness, a correct specs implemntation and a correct
directives implementation will handle (1) _in the same way_.  So I don't
think there's any reason to prefer directives over specs as far as (1)
itself is concerned.

IMO, the three cases are in order of importance, with the most important
first.  I'm actually pretty surprised we care about (3).  After all,
it's not like we support the sequence:

    gcc foo.c -o foo.s
    as foo.s -o foo.o
    ld foo.o -o foo

The link line will fail on almost all targets.  I thought advice had
always been: do everything through the gcc driver -- using the same
gcc target options -- unless you really know what you're doing.
And if the user really knows what they're doing, how do we know
that the suggested behaviour for (3) is correct?  If the user does:

    gcc -mtune=X foo.c -o foo.s
    as -mtune=Y foo.s -o foo.o

how do we know that assembler should ignore -march=Y and tune foo.s
for X instead (which is what the directives approach implies)?
If the user is going to the trouble of separating out the compilation
and assembly steps like this, it could well be that they're deliberately
wanting to try out different assembly modes for the same .s file,
in order to see what affect they have.

The assemblers on some targets (guess which one I'm thinking of)
have an optimisation option.  If we translate gcc driver -O options
into assembler optimisation options, should we hard-code the .c->.s
optimisation level in the .s file, so that:

    gcc -O0 foo.c -o foo.s
    gcc -O2 foo.s -o foo.o

assembles foo.s at -O0 instead of -O2?  That seems a bit counter-
intuitive to me, but if we don't do it for -O, why do it for another
optimisation option like -mtune?

Also consider:

    (a) gcc -mtune=X foo.c -o foo.s
    (b) gcc -mtune=Y foo.s -o foo.o
    (c) gcc -mtune=Z foo.o -o foo

assuming that the -mtune options are either explicit or implied.
At link time -- (c) -- it's the -mtune=Z option that counts, not the
-mtune=X or -mtune=Y option.  If we have multilibs tuned for Z, those
are the ones that will be used.  So why should it be the -mtune=X option
rather than the -mtune=Y option that counts at (b), as the directives
approach implies?  It seems rather inconsistent.

In contrast, specs seem to provide a clear and pretty consistent
interface IMO.

Richard


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