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: [patch] Introduce dumpfile.h, clean up tree-pass.h dependencies


On Mon, Jul 16, 2012 at 11:00 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Fri, Jul 13, 2012 at 3:38 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> Hello,
>>
>> The attached monster patch re-organizes a lot of includes to avoid
>> dependencies on tree-pass.h just for having dump_file available.
>>
>> I've used the following "rules" to decide what needs to go where:
>>
>> * tree-dump.h should be independent of the pass manager, i.e. not
>> include tree-pass.h.
>>
>> * passes that do not need dumping of GENERIC do not need tree-dump.h either.
>>
>> * Any file that defines an opt_pass may include tree-pass.h.
>>
>> * If a file includes tree-pass.h, it does not need to include
>> dumpfile.h or timevar.h, because tree-pass.h provides these already
>> (the *opt_pass structs depend on them)
>>
>> * If a file does not include tree-pass.h, but it needs dump_file, it
>> should include dumpfile.h. Likewise for timevar.h. This category of
>> files are the implementation files for supporting code, like alias.c
>> and cfg*.c.
>>
>> With those rules in mind, my hackathon started and the result is
>> attached. I had to move a few functions around, but not very much. I
>> also uncovered a bug in one of the DF files, where it was trying to
>> use get_insns without including emit-rtl.h.  No DF file should emit
>> RTL, so I don't want to include emit-rtl.h there, so I removed that
>> dumping (which was only for debugging purposes anyway, and obviously
>> not tested in a while or I wouldn't have run into this problem to
>> begin with :-)
>>
>> Bootstrapped&tested on powerpc64-unknown-linux-gnu and on
>> x86_64-unknown-linux-gnu. OK for trunk?
>
> You moved get_ref_base_and_extent to tree.c - any reason for that?

Yes, tree.c uses it (build_simple_mem_ref_loc) and I don't want tree.c
to depend on tree-dfa.c. Longer-term I'd like to split tree.c and
tree.h, and this function and the two others you mention below could
go into e.g. tree-anal.c.

> It is similar to get_inner_reference which is in expr.c and similar to
> get_addr_base_and_unit_offset which is still in tree-dfa.c.  I'd prefer
> to have it stay where it is for this patch.

OK.

Ciao!
Steven


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