This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: a .NET alternative (GJC et al)
- To: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Subject: Re: a .NET alternative (GJC et al)
- From: Florian Weimer <Florian dot Weimer at RUS dot Uni-Stuttgart dot DE>
- Date: 09 Aug 2001 18:46:41 +0200
- Cc: gcc at gcc dot gnu dot org
- References: <200107280643.XAA13992@morrowfield.home><20010728151858.A10834@murlibobo.cs.mu.OZ.AU><87lml9kt2r.fsf@creche.redhat.com><200107290857.BAA21039@morrowfield.home><20010730134749.A23349@hg.cs.mu.oz.au><tgvgkartcy.fsf@mercury.rus.uni-stuttgart.de><20010731085348.A18328@hg.cs.mu.oz.au>
Fergus Henderson <fjh@cs.mu.oz.au> writes:
[GC, backend cooperation
> The reason that this technique works is that the back-end compiler
> can't do any fancy optimizations on locals.p and local.q, since
> &locals has been stored in a global variable and so any function
> call might update them.
But there is a subtle form of backend cooperation lurking here: You
assume that the backend does not know too much about the functions
being called. In fact, if there isn't a collector, the stack frame
marking does not have any externally visible effect, so it is legal to
optimize it away completely.
In order to make things work, you have to throw in a few volatile
qualifiers here and there, I think, which will deteriorate performance
further.