Re: equality of label addresses

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

On 29-Jan-2003, Richard Henderson <rth@redhat.com> wrote:
> On Wed, Jan 29, 2003 at 03:07:38PM +1100, Fergus Henderson wrote:
> > The program below works fine with `-O0', but gets an assertion failure
> > with `-O2', because with `-00', the two labels `label2' and `label3'
> > have different addresses, but with `-O2', GCC does some duplicate code
> > elimination and so the two labels end up pointing to the same code.
> > (This is with gcc 2.95 and 3.1.  I haven't tested this with
> > the current mainline.)
> > Is this a valid optimization?
> 
> IMO yes.  If you goto that label, do you not get correct results?

Yes.  But if you are associating information with the label,
e.g. via a hash table that maps label addresses to corresponding
information about the label, then you are somewhat screwed;
GCC will combine labels that happen to have the same code,
even if they don't have the same associated information.
So in that case you do not get correct results.

The technique of associating information with code addresses
is used to implement the Mercury debugger, and more generally
is used in other compilers for implementing features such as
garbage collection and exception handling.  It was considered
important enough by the designers of C-- that they included
explicit support for it as part of the C-- language.  It is, IMHO,
an important use case.

Any suggestions on how to efficiently support this?

Right now my best solution is for the Mercury compiler to generate code
of the form

	label1:
		asm volatile ("" :: "g"(1));
		...
	label2:
		asm volatile ("" :: "g"(2));
		...
	label3:
		asm volatile ("" :: "g"(3));

where the value passed to the empty asm volatile is different for
each label.  This seems to be enough to ensure that the different labels
will get different addresses, without causing any additional code to
get generated.  However, I feel like I'm on thin ice here...
is it reasonable to assume that labels followed by asm volatile
instructions with different input arguments will have distinct
addresses?

> > Even more worrying is that GCC 3.1 will do the same optimization
> > even if you insert ` asm volatile("nop"); ' in front of each
> > call to foo()
> 
> Unless I'm misunderstanding you, we did not combine two dynamic
> invocations of the asm.  Instead we combined two instances of
> the asm seen on different execution paths.  Thus the sequence
> of instructions seen at runtime are identical.

That is correct; you are not misunderstanding me.

> Thus I believe this optimization to be valid as well.
> 
> > If not, then I think the documentation for volatile asm instructions
> > should be clarified.
> 
> Care to write the patch?

OK, shall do (when time permits).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.