Re: RFC: Preserving order of functions and top-level asms via cgraph

[Mark Mitchell <mark at codesourcery dot com>]

Daniel Jacobowitz wrote:
> This has been on the table for ages, but no one's gotten around to doing it. 
> I'm attaching a (mostly untested) patch which fixes the simple cases.  For
> instance, it causes this test to come out in the expected order:
>
> void func1() { }
> asm ("# ASM");
> void func2() { }
>
> It doesn't handle variable declarations, and it won't be useful until it
> does.  Right now declarations are written to the assembly file early, before
> functions are assembled.  Steven pointed out (thank you, Steven) that this
> is much easier on the tree-profiling branch, where that is no longer the
> case.  So, I'm not going to extend the patch to declarations until that
> piece is merged.
>
> In the mean time, any fundamental objections to the approach?

Your primary objective (get rid of -fno-unit-at-a-time) is one that I 
strongly support.  I also agree that your strategy of recording asms in 
cgraph makes sense, assuming that we want to continue to support 
interleaving asms and other things, with well-defined ordering.

My only question is whether we do want to continue to support that 
ordering.  In your example program, the compiler might someday notice 
that func1 and func2 were identical, and emit a single function, with 
two aliases.  There are other situations where moving things across an 
asm might make sense, and if the translation unit depends on the 
positioning of asms, there are likely things that the compiler doesn't 
fully understand about the translation unit, which seems dangerous.  (In 
other words, the asms aren't orthogonal to the rest of the translation 
unit, but the compiler doesn't know in what ways they are non-orthogonal.)

Saving up all the asms and then emitting them either at end-of-file 
might make sense.

I do understand that there are some things that one can do with the 
current system that one probably couldn't under my proposal, but I'm not 
sure if they're sufficiently compelling.  They might well be; I just 
don't know.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304