This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/38819] [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop
- From: "dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Jan 2009 20:48:44 -0000
- Subject: [Bug tree-optimization/38819] [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop
- References: <bug-38819-230@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from dberlin at gcc dot gnu dot org 2009-01-16 20:48 -------
Subject: Re: [4.2/4.3/4.4 Regression] trapping
expression wrongly hoisted out of loop
Hmmm.
The only way you could get the CFG to represent that any call may exit
would be to calls terminate bb's and have an edge from every call to
exit.
:(
We actually do this with noreturn edges.
It's probably a lot easier to just not move trapping expressions for now.
On Fri, Jan 16, 2009 at 3:04 PM, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-16 20:04 -------
> PRE shouldn't cause new evaluations - the issue here is that the CFG
>
> # BLOCK 2 freq:900
> # PRED: ENTRY [100.0%] (fallthru,exec)
> si1_3 ={v} a;
> si2_4 ={v} b;
> # SUCC: 3 [100.0%] (fallthru,exec)
>
> # BLOCK 3 freq:9100
> # PRED: 8 [100.0%] (fallthru) 2 [100.0%] (fallthru,exec)
> # i_31 = PHI <i_12(8), 0(2)>
> foo ();
> x.0_6 ={v} x;
> if (x.0_6 == 8)
> goto <bb 4>;
> else
> goto <bb 7>;
> # SUCC: 4 [28.0%] (true,exec) 7 [72.0%] (false,exec)
>
>
> # BLOCK 7 freq:6552
> # PRED: 3 [72.0%] (false,exec)
> goto <bb 5>;
> # SUCC: 5 [100.0%] (fallthru)
>
> # BLOCK 4 freq:2548
> # PRED: 3 [28.0%] (true,exec)
> i_7 = i_31 + 1;
> # SUCC: 5 [100.0%] (fallthru,exec)
>
> # BLOCK 5 freq:9100
> # PRED: 7 [100.0%] (fallthru) 4 [100.0%] (fallthru,exec)
> # i_1 = PHI <i_31(7), i_7(4)>
> D.1253_8 = si1_3 % si2_4;
> r.1_10 ={v} r;
> D.1254_9 = D.1253_8 + r.1_10;
> r.2_11 = D.1254_9 + i_1;
> r ={v} r.2_11;
> i_12 = i_1 + 1;
> if (i_12 <= 99)
> goto <bb 8>;
> else
> goto <bb 6>;
> # SUCC: 8 [90.1%] (true,exec) 6 [9.9%] (false,exec)
>
> # BLOCK 8 freq:8200
> # PRED: 5 [90.1%] (true,exec)
> goto <bb 3>;
> # SUCC: 3 [100.0%] (fallthru)
>
> # BLOCK 6 freq:900
> # PRED: 5 [9.9%] (false,exec)
> abort ();
> # SUCC:
>
> does not model the fact that foo () does not return.
>
> Danny, do you have any suggestion (besides to try to avoid trapping stuff
> somehow) to model this?
>
>
> --
>
> rguenth at gcc dot gnu dot org changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |dberlin at gcc dot gnu dot
> | |org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819