This is the mail archive of the 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: RFC - Next refactoring steps


On Thu, 5 Sep 2013, Andrew MacLeod wrote:

> 1 -  I think we ought to split out the data structures from gimple.h into
> gimple-core.h, like we did with tree.h


> gimple.h.  That won't  really affect my work.  I think it probably ought to be
> done for clarity eventually.    gimple.h would then simply become a collector
> of "gimple-blah.h" files which are required for a complete gimple system.

Doesn't make sense to me.  If you split it into multiple files, just to 
then create a wrapper called gimple.h including all of them again for the 
consumers you can just as well have all of it in one file.

> 2 - all the uses of TREE_NULL to refer to an empty/nonexistent object...  it
> is no longer in tree-core.h, which I think is correct. what should we start
> using instead in converted files?  options are:
>   a)  0
>   b) NULL
>   c) something we define as 0, like GIMPLE_NULL

I think I'd prefer 0, but it creates a problem with varargs functions, so 
you'd always need "(gimple)0" for those, which you'd probably hide behind 
a macro, at which point you'd have two forms for the nil gimple ("0" and 
that macro), for consistency you'd want to use the macro in place of "0" 
also in the non-varargs places, et voila, you're back to "NULL" or 

> 3) remove tree.h from other .h files
>   Now that tree.h is split, there are a few .h files which directly include
> tree.h themselves. It would be nice if we could remove the implementation
> requirement of tree.h to ease moving to gimple.h. The 4 files are :
>  ipa-utils.h   lto-streamer.h  streamer-hooks.h  tree-streamer.h
> It should be possible to not directly include tree.h itself in these files.
> Worst case, the header file is included  after tree.h from the .C files.. that
> seems to be the way most of the other include files avoid including tree.h
> directly.

That can be done right now I think.

For the rest of the topic, tree vs gimple: I don't see much value in that.  
Why create a gimple_expr type that basically is just tree?  You can as 
well use tree then.


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