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] Split builtins.c


Roger Sayle writes:
 > 
 > On Sun, 25 Apr 2004, Jerry Quinn wrote:
 > > One of the beginner projects suggests splitting up big files, so I
 > > took a crack at builtins.c.  I split off the fold_builtin_XX functions
 > > into fold-builtin.c.
 > 
 > 
 > Whilst this patch is exactly the thing that needs to be done, I doubt
 > you could have chosen a worse time to propose it.  To quote Mark's
 > status reports, mainline is currently in a "holding pattern" awaiting
 > the merge of tree-ssa.  Whilst the majority of GCC's new tree-ssa
 > implementation is in new tree-*.[ch] files, some files (including
 > toplev.c, fold-const.c and builtins.c) will be significantly affected
 > by the merge.  For this reason, I believe that major reorganizations
 > of these files should ideally wait until after the merge.

No problem.  It was only a couple hours of work to do the split, so it
shouldn't be too hard to put on the back burner and redo.  Are there
other candidate files ripe for picking that are safer?

 > On a more positive note, builtins.c is significantly larger on the
 > tree-ssa branch, due to even more unnecessary duplication, and will
 > therefore benefit even more from splitting these routines out into
 > their own fold-builtins.c.

Cool.  I was disappointed that builtins.c still remained 3x bigger
than fold-builtins.c, but I didn't beat on it any harder.

 > On the technical side, I think your split between folders and expanders
 > is the best one.  Yes, there's some duplication between the two, but
 > this is one of the things that needs to be eliminated.  Tree-level
 > transformations need to be moved from the expanders to the folders.
 > Originally, I considered preserving the current behaviour by having
 > the expanders call the folders, but I now agree with RTH that this
 > should be unnecessary; the expanders should be able to assume their
 > tree has been folded/canonicalized before RTL expansion-time.

I probably just got lucky :-)  I pulled on a thread, and it
disentangled cleanly - plus fold-const.c was already there, suggesting
that split.

What do you think about Andrew and Nathanael's suggestion of just
pulling out the math builtins?  I'm a neophyte here - not too familiar
with the structure of the deep innards.

 > Once the tree-ssa branch is merged, it's the folders and the simplifiers
 > that will need to be reintegrated.

I'm not quite sure what you're referring to here...

Jerry


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