This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: struct function cleanup part I
Tom Tromey wrote:
Richard> I don't see much value in arguing for future features if
Richard> nobody is currently working in them - Mark, are you working
Richard> on multi-threaded RTL world?
To answer Richard, no I'm not working on a multi-threaded compiler.
That would be fun though! My motivation here is just to try to avoid
making software engineering decisions that will make our lives harder later.
It seems to me that it isn't very hard to write new code in a
reusable, object-oriented way, even in C. There are plenty of
examples of this, even in GCC itself (e.g, the C parser). I'd prefer
GCC to go this route rather than continue with lots of global
variables. I don't think there are big drawbacks, and there are
possible advantages.
Exactly.
(Doing single-inheritance OO in C is pretty easy, and not even that
ugly. You end up with things like "x->vtbl->f()" for "member" functions
and "x->i" for fields. And, I didn't even go that far in the C++
parser; it's all just cp_parser_x functions taking a cp_parser *, so
there's no inheritance -- but there is re-entrancy. Of course, the rest
of the front end isn't re-entrant, so I can't claim this is terribly
useful -- yet.)
Jan, I'm not picking on your patch. I understand why it's a step
forward. I'm certainly not asking you to revert it. I'm not trying to
demand on follow-on patches; if you're too busy, this isn't the most
important problem.
I'm just trying to advance the idea that we should avoid globals for
things that aren't necessary the only one of something. I think that
forcing ourselves to think about at least "abstract data structures"
(i.e., treat data as opaque, define the operations available on it) is a
good way to improve our code. It's perfectly feasible to do that in C;
just takes a little discipline.
As you say downthread:
4) RTL stuff that is local to function being compiled should go
completelly off cfun, since we don't need to have them all allocated
for all functions. I've invented RTL structure for this and made it
static since I wasn't able to settle down on projection where our APIs
will go.
Instead of get_rtl_for_fn (decl), I'm perfectly happy with cfun->rtl. I
was just trying to give you the freedom to avoid the pointer-per-cfun by
using a hash table, etc.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713