This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
- From: "dnovillo at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 24 Sep 2004 10:29:08 -0000
- Subject: [Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
- References: <20040518194300.15524.pinskia@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From dnovillo at redhat dot com 2004-09-24 10:29 -------
Subject: Re: [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases
On Fri, 2004-09-24 at 02:13, law at redhat dot com wrote:
> We can turn that into
>
> switch (x)
> {
> case 42:
> x = 42;
> whatever
> }
>
This is what I'm working with as part of VRP. The idea is to insert
ASSERT_EXPR that act as special assignments. I have a WIP patch if you
are interested, but I at the moment I'm paying more attention to fixes
for 4.0.
> 1. Is it really necessary to mark these assignments as undeletable
> until late in the SSA path (that's something Kenny suggested
> as well).
>
The ASSERT_EXPRs are naturally undeletable if they are used. When we
find:
if (x_3 == y_9)
{
x_4 = ASSERT_EXPR (x_3 == y_9)
if (x_4 > 4)
...
}
If you end up knowing something about y_9, you may be able to fold the
inner conditional into a constant. If you never use x_4, then the
ASSERT_EXPR is naturally dead and goes away.
ASSERT_EXPRs are inserted before we go into SSA and are treated as
regular IL elements. VRP would propagate and fold them using the SSA
propagator. This part is still to be done. Initially I had fused this
with CCP, and that didn't work too well.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524