[m-dev.] for review: GCC back-end: variable scoping

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Jan 10 15:28:26 AEDT 2001


On 10-Jan-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 07-Jan-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > Estimated hours taken: 12
> > 
> > Implement proper variable scoping.
> > This has two consequences:
> > - the generated code uses less stack space, since various
> >   whose scope does not overlap get assigned the same stack slot
> > - local variables now show up in gdb.
> > 
> > mercury/compiler/gcc.m:
> > 	New routines start_block and end_block.
> > 
> > mercury/compiler/mlds_to_gcc.m:
> > 	Call the new routines.
> > 
> > gcc/mercury/mercury-gcc.c:
> > 	- Call pushdecl() for builtin types and for local variables,
> > 	  to ensure that they get recorded in gcc's symbol tables,
> > 	  so that it will generate debugging information for them.
> > 	- Fix a bug (copied from the toy.c example front-end)
> > 	  where it was clobbering the function DECL_ARGUMENTS field.
> > 	- Simplify the spec1() macro by eliminating its first arg.
> 
> This also looks fine.
> 
> I was about to comment that this backend is actually relatively
> simple, once you understand what all the C macros actually do.
> So maintenance might not be as bad as I first thought.
> 
> But then I looked at the time taken for this one.
> I assume it was tracking down the bug copied from from toy.c that took
> all that time?

That was quite time consuming, yes.  About 5 hours, at a guess.
But there were some other things as well:

	- spent a lot of time reading the source code for the other
	  GCC front-ends to try to understand how they handle variable
	  scoping

	- spent quite a bit of time debugging a problem where I'd
	  called spec1() on something with array type.  spec1()
	  overwrote the TREE_TYPE() field to point to itself,
	  which is the right thing to do for atomic types (since dbx
	  requires it), but not the right thing to do for array types,
	  since for arrays the TREE_TYPE() field holds the array
	  element type.  This caused gdb to go into an infinite loop,
	  with no output, when trying to print out that type (with the
	  "ptype" command).  It took me quite some time to figure out
	  why that was happening.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list