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: RFC: Preserving order of functions and top-level asms viacgraph


It looks like the "keep the ordering" argument has the upper hand
at the moment, so FWIW...

Mark Mitchell <mark@codesourcery.com> writes:
> There might also be better ways to do the things that people are
> currently doing, so that we could break existing code, but provide a
> useful workaround.  For example, we could add an asm_before function
> attribute that contained literal assembly code to be emitted directly
> before the function.  That might serve the MIPS kernel needs, in a
> cleaner way than the current implicit ordering constraint.

...I'd like to support this idea.  As it happens, the MIPS kernel has
since seen the light, and doesn't use that hack anymore.  The asm simply
jumps to the C entry point instead of falling through.  But if people
really care about avoiding the jump, I think this sort of attribute is
much less fragile than the top-level asm trick.

Using an attribute would automatically ensure that the alternative asm
code gets put into the right section, something that isn't really
guaranteed with top-level asms.  (The user has to switch sections
explicitly.)  We could also provide a syntax for declaring the
alternative entry point symbol, making the asm code easier to write
as well as exposing it at the C level.

I suppose this is just echoing what's already been said, but I think
many of the current order-sensitive uses of top-level asms are simply
there because gcc doesn't provide a better way of doing the same thing.
If we provide the appropriate extensions, that shold be better for both
gcc users (because there's a documented extension that is more likely to
work with future compilers) and for gcc developers (because gcc has a
better idea of what the user's code is actually doing).

Trying to keep the current top-level asm ordering seems like fighting
against the tide of gcc development.  And it isn't just a case of seeing
what existing code uses this ordering.  If we make the ordering assumption
semi-official, it will encourage folks to add new "try it and see if works"
uses of the feature, which will make it even harder to remove in future.

Anyway, if we try to keep the ordering, I think we should document
exactly what it is we guarantee and what we don't.

Richard


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