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
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Diego Novillo <dnovillo at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 Feb 2004 05:45:19 -0700
- Subject: Re: [tree-ssa] Loop header copying on trees
- Reply-to: law at redhat dot com
In message <20040216120759.GA6792@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak writ
es:
>I suspect this is due to the copied headers being often eliminated.
Likewise. Which leads to a rather interesting question -- can we predict
when we are likely going to be able to eliminate the header (or when we
can not). If so, then we could use that to tune when we do header
copying.
> 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).
Yes, we get a certain amount of virtual header copying via jump threading.
It would certainly be interesting to see if loop header copying at the
tree level generally makes things larger or smaller so that we could
make an informed decision :-)
>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).
I'm certainly not going to argue that those are not useful -- in fact, they are
one of the biggest reasons to keep some of the options. Though I'd really
prefer to have true unit testing to deal with #1, but that's still a ways
off.
>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),
Which is what -ON is for :-)
> and a generic way providing the means to control precisely what is done
> (for developers).
Well, as a developer, if I want to control things very precisely, I'll
twiddle whatever I need, flags, source code, whatever.
jeff