> Like this? Regtested/bootstrapped on x86_64-linux, ok for trunk?
>
> 2012-12-01 Marek Polacek
>
> PR middle-end/54838
> * cprop.c (bypass_block): Determine number of latches. Return
> when there is more than one latch edge.
>
> * gcc.dg/pr54838.c: New test.
That's
On Fri, Nov 30, 2012 at 11:00:28PM +0100, Eric Botcazou wrote:
> OK, let's tweak the patch as follows:
> 1) when current_loops is not NULL, we compute may_be_loop_header and whether
> the loop has more than 1 latch edge exactly,
> 2) when current_loops is NULL, we use your above method to do the
> Yikes, sorry, it wasn't clear to me what PROP_loops really does. Anyway,
> I think I have a better fix now. The problem is just that when removing
> BB 4 (which was a header), we have to zap ->header and ->latch. We
> already have code for this:
>
> if (current_loops != NULL
> && e->s
> RTL cprop seems to run both before and after RTL loop optimizers (currently
> after RTL loop optimizers we throw away loops - an arbitrary chosen point
> before IRA across which I could not get things to work). Thus you could do
>
> if (current_loops)
> is_loop_header = bb == bb->loop_fat
On Fri, Nov 30, 2012 at 10:01:37AM +0100, Richard Biener wrote:
> RTL cprop seems to run both before and after RTL loop optimizers (currently
> after RTL loop optimizers we throw away loops - an arbitrary chosen point
> before IRA across which I could not get things to work). Thus you could do
>
On Thu, Nov 29, 2012 at 6:43 PM, Eric Botcazou wrote:
>> Yikes, sorry, it wasn't clear to me what PROP_loops really does. Anyway,
>> I think I have a better fix now. The problem is just that when removing
>> BB 4 (which was a header), we have to zap ->header and ->latch. We
>> already have code
> Yikes, sorry, it wasn't clear to me what PROP_loops really does. Anyway,
> I think I have a better fix now. The problem is just that when removing
> BB 4 (which was a header), we have to zap ->header and ->latch. We
> already have code for this:
>
> if (current_loops != NULL
> && e->s
On Thu, Nov 29, 2012 at 04:50:19PM +0100, Steven Bosscher wrote:
> > 2012-11-29 Marek Polacek <>
> >
> > PR middle-end/54838
> > * cprop.c (bypass_block): Set header and latch to NULL when
> > BB has more than one latch edge.
> > (n_latches): New variable.
>
> You
On Thu, Nov 29, 2012 at 4:38 PM, Marek Polacek wrote:
> On Thu, Nov 29, 2012 at 09:34:31AM +0100, Richard Biener wrote:
>> Definitely not - that means to not preserve loops until after cprop. The
>> goal
>> is to preserve loops everywhere!
>
> Yikes, sorry, it wasn't clear to me what PROP_loops r
On Thu, Nov 29, 2012 at 04:38:52PM +0100, Marek Polacek wrote:
> 2012-11-29 Marek Polacek
>
> PR middle-end/54838
> * cprop.c (bypass_block): Set header and latch to NULL when
> BB has more than one latch edge.
> (n_latches): New variable.
Of course here should be (n_la
On Thu, Nov 29, 2012 at 09:34:31AM +0100, Richard Biener wrote:
> Definitely not - that means to not preserve loops until after cprop. The goal
> is to preserve loops everywhere!
Yikes, sorry, it wasn't clear to me what PROP_loops really does. Anyway,
I think I have a better fix now. The proble
On Thu, Nov 29, 2012 at 9:56 AM, Steven Bosscher wrote:
> On Thu, Nov 29, 2012 at 9:34 AM, Richard Biener wrote:
>> On Wed, Nov 28, 2012 at 7:24 PM, Marek Polacek wrote:
>>> I admit I'm not sure what to look at, maybe cprop should have in
>>> properties_destroyed PROP_loops? Well, then we need to
On Thu, Nov 29, 2012 at 9:34 AM, Richard Biener wrote:
> On Wed, Nov 28, 2012 at 7:24 PM, Marek Polacek wrote:
>> I admit I'm not sure what to look at, maybe cprop should have in
>> properties_destroyed PROP_loops? Well, then we need to remove one
>> assert in loop-init.c. So something like:
>
>
On Wed, Nov 28, 2012 at 7:24 PM, Marek Polacek wrote:
> On Wed, Nov 28, 2012 at 10:52:17AM +0100, Eric Botcazou wrote:
>> No, I don't think that's the problem. The above messages are admittedly a
>> bit
>> terse, they should say:
>>
>> JUMP-BYPASS: Proved reg 59 in jump_insn 15 equals constant (
On Wed, Nov 28, 2012 at 10:52:17AM +0100, Eric Botcazou wrote:
> No, I don't think that's the problem. The above messages are admittedly a
> bit
> terse, they should say:
>
> JUMP-BYPASS: Proved reg 59 in jump_insn 15 equals constant (const_int 3 [0x3])
> when BB 4 is entered from
> We then end up with
> Redirecting fallthru edge 3->4 to 6
> JUMP-BYPASS: Proved reg 59 in jump_insn 15 equals constant (const_int 1
> [0x1]) Bypass edge from 3->4 to 6
> Redirecting fallthru edge 9->4 to 5
> JUMP-BYPASS: Proved reg 59 in jump_insn 15 equals constant (const_int 3
> [0x3]) Bypass e
In this PR, for the C testcase, in .cse1 we have:
ENTRY
|
|
2
|
|
+ 4 --+
|/ \ |
| / \ |
| 6 5|
| /\ |\
17 matches
Mail list logo
