This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Introduce dumpfile.h, clean up tree-pass.h dependencies
On Mon, Jul 16, 2012 at 11:12 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> 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.
Seems to break build with graphite for me:
/space/rguenther/src/svn/trunk/gcc/graphite-dependences.c: In function
'graphite_legal_transform':
/space/rguenther/src/svn/trunk/gcc/graphite-dependences.c:534:
warning: implicit declaration of function 'timevar_push'
/space/rguenther/src/svn/trunk/gcc/graphite-dependences.c:534: error:
'TV_GRAPHITE_DATA_DEPS' undeclared (first use in this function)
...
/space/rguenther/src/svn/trunk/gcc/graphite-clast-to-gimple.c: In
function 'translate_clast_user':
/space/rguenther/src/svn/trunk/gcc/graphite-clast-to-gimple.c:1102:
error: 'TODO_update_ssa' undeclared (first use in this function)
...
/space/rguenther/src/svn/trunk/gcc/graphite-clast-to-gimple.c:1644:
error: 'TV_GRAPHITE_CODE_GEN' undeclared (first use in this function)
...
/space/rguenther/src/svn/trunk/gcc/graphite-sese-to-poly.c:2341:
error: 'TODO_update_ssa' undeclared (first use in this function)
...
> Ciao!
> Steven