This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: make reg_equiv_memory_loc visible to garbage collector (Was:


> This looks mostly OK to me.  I don't see why you need to put 
> reg_equiv_memory_loc_varray in rtl.h.  It would make more sense to put 
> it in reload.h.

I tried that first, but then I found out that GTY stuff needs to be in
one of GTFILES, and for each of these source headers another header is
generated that has to be included in some C source file.
And after all, reg_equiv_memory_loc_varray is not used exclusively in
reload, but also in other parts of the register allocator, so rtl.h
seemed like a suitable alternate home for it.

It seemed less intrusive to put the declaration for
reg_equiv_memory_loc_varray into rtl.h than to include reload.h
in the gengtype machinery.

However, I don't have a strong opinion on that; if you think I should do
the latter, please say so and I'll modify my patch to do that.
I suppose the right C file to include gt-reload.h would be reload1.c

>                  Also, the VARRAY_RTX_INIT call in toplev.c looks funny. 
>   I think this makes more sense in init_reload() in reload.c.

I thought of it as initializeing the garbage collector, and
that's what this piece of general_init does.

You have a point that it can also considered to be initializing variables
used by reload.  However, reg_equiv_memory_loc_varray is used before
the first call of reload.  I see that init_reload is called currently
from init_backend, so that should be all right for now, but is it safe
to assume that init_reload will always be called before
rest_of_handle_old_regalloc / reg_alloc ?
The comment in reload.c suggests otherwise.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]