This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Loop header copying on trees
Hello,
> >> >> + ftree-ch
> >> >> + Common
> >> >> + Enable loop header copying on trees
> >> >> +
> >> >>
> >> >Include a small blurb describing why header copying is beneficial.
> >> >Also, do we really want to control it with a flag? Some of the -f flags
> >> >we have in tree-ssa should probably disappear.
> >> And in fact, I don't think we really want to have a knob to turn off
> >> header copying.
> >
> >why not? At the very least, we probably do not want it enabled at -Os.
> Funny -- we experimented with that a while back and we actually got
> more compact code copying loop headers!
I suspect this is due to the copied headers being often eliminated. The
jump threading on tree-ssa does this kind of loop header copying
already, so I assume it might no longer be true (although I haven't
tested it).
> >Also I do not see why having a precise control over what the compiler
> >does should be wrong.
> The fundamental problem is you have to know far too much about the
> compiler to even begin to estimate how the gazillion knobs might
> affect the output. I've believed for a very long time that GCC provides
> far too many knobs and switches and all it does is lead to mass
> confusion.
yes, this might be a problem. On the other hand, there are a lot of
situations where you would like to have as precise control as possible:
1) For writing testcases to testsuite, it would be very nice to be be
able to disable all (nonesential) components except for the one you
intend to test.
2) When debugging a misscompilation, it would often be useful to control
the optimization options at least on per-function level (and
preferably finer).
Perhaps we can have both, now that we have the generic way of
pass management -- we could have easy to use flags only for controlling
important features (for users), and a generic way providing the means to control
precisely what is done (for developers).
Zdenek