On Wed, Sep 11, 2013 at 2:30 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 09/11/2013 04:45 AM, Richard Biener wrote: >> >> On Tue, Sep 10, 2013 at 9:19 PM, Andrew MacLeod <amacl...@redhat.com> >> wrote: >>> >>> Here's a start at restructuring the whole tree-flow.h mess that we >>> created >>> back in the original wild west tree-ssa days. >>> >>> First, almost everyone includes tree-flow.h because it became the kitchen >>> sink of functionality. Really, what we ought to have is a tree-ssa.h >>> which >>> anything that uses basic tree-ssa functionality includes, and that'll be >>> the >>> main include for SSA passes. Other prototypes and such should come from >>> other appropriate places. Doing this in one step is basically impossible. >>> so >>> here is that first few steps, structured so that it's easier to review. >>> >>> I changed everywhere which includes tree-flow.h to include tree-ssa.h >>> instead. tree-ssa.h includes tree-flow.h first, which makes it >>> functionally the same from a compiling point of view. >> >> You mean that doing the restructure and only adding includes that are >> required to make compile work again wasn't feasible...? > > Not really for this first split... eveyrthing that required tree-flow.h > basically requires tree-ssa.h. Once everything has been separated from > tree-flow.h and put in their right places, It's easy to see exactly which > parts are required where, and by tackling each .c file once that uses > tree.ssa.h I can get it down the the bare bones for what was required from > the original bloated tree-flow.h. > >>> I also moved everything from tree-flow.h and tree-flow-inline.h that is >>> related to tree-ssa.c functions into tree-ssa.h. There were also a few >>> function prototypes sprinkled in a couple of other headers which I moved >>> into tree-ssa.h as well. I have verified that every exported function in >>> tree-ssa.c has a proto in tree-ssa.h, and is listed in the same order as >>> the >>> .h file. >> >> Note that in general there isn't a thing like "tree SSA" anymore - it's >> "GIMPLE SSA" now ;) Not that we want gigantic renaming occuring now, >> just if you invent completely new .[ch] files then keep that in mind. > > > I considered just making it just ssa.h, but maybe this isn't the time... > Probably easier to do a mass rename very early in stage 1... until then I > figure it probably makes sense to make the .h match the .c file.. yes, > for a new pair, I'd not bother with tree-* > >> >> That is, if you moved stuff to tree-ssa.h that has no definition in >> tree-ssa.c >> then I'd rather have a new gimple-ssa.h that doesn't have a corresponding >> .c file (for now). > > Ah, i see. Although mulling it over last night, Im marginally in favour > of having a separate .h for for each .c... Then things like > tree-ssa-ununit.h which are only used in one or two places can simply be > included in the one or two .c files they are required for. That way we > preserve tree-ssa.h to only include the "commonly required" .h files which 6 > or more .c files require. (to pick an arbitrary number :-) This will help > reduce the include web for rebuilding/compiling. I also note your response > in the other patch... First I will try to restructure whats in the file > before resorting to a new .h file in these cases. I'll keep a > gimple-ssa.h "aggregator" on the backburner until it looks like it will be > needed. > >>> Compiling this change indicated that there were a few files which >>> required >>> functionality from tree-ssa.c which really don't belong there. In >>> particular, useless_type_conversion_p and types_compatible_p are used by >>> the C++ front end and other places which don't really care about SSA. So >>> I >>> moved them into more appropriate places... tree.c and tree.h >> >> Well, those functions are only valid when we are in GIMPLE (the GIMPLE >> type system is less strict than the GENERIC one), so tree.[ch] isn't >> appropriate. >> gimple.[ch] would be. But I wonder where it's used from the FEs - that's >> surely >> looking wrong (unless it's in a langhook). But yes, the functions are not >> in any way about SSA but only GIMPLE. > > > OK, that wasn't obvious from the function itself (it only ever deals with > trees), but that being the case, I'll move them both to gimple.[ch] instead. > That seems more appropriate and I will comment it as gimple compatible only. > > Looks like there is a langhook... > c-family/c-common.c: && lang_hooks.types_compatible_p (TREE_TYPE (t1), > TREE_TYPE (t2))) > > However each front end seems to provide their own version of > types_compatible_p and use that... ( c_types_compatible_p and > cxx_types_compatible_p). lto.c has gimple_types_compatible_p()... but does > also use types_compatible_p() in lto-symtab.c :-P
Yeah, but lang_hooks.types_compatible_p () is not equal to types_compatible_p () :P The langhook seems to be only used from c-family/ and thus is a C-family hook now ;) Richard. > > Andrew
