On 09/12/11 14:59, Eric Botcazou wrote:
>> 2011-12-07 Tom de Vries
>>
>> * cfgcleanup.c (try_optimize_cfg): Replace call to delete_isns_chain by
>
> delete_insn_chain
>
>> call to delete_insn. Remove code to reorder BASIC_BLOCK note and
>> DELETED_LABEL note, and move it to ...
> 2011-12-07 Tom de Vries
>
> * cfgcleanup.c (try_optimize_cfg): Replace call to delete_isns_chain by
delete_insn_chain
> call to delete_insn. Remove code to reorder BASIC_BLOCK note and
> DELETED_LABEL note, and move it to ...
> * cfg_rtl.c (delete_insn): Change retu
On 06/12/11 14:25, Michael Matz wrote:
> Hi,
>
> On Tue, 6 Dec 2011, Tom de Vries wrote:
>
>> what should be the 'next' returned by delete_insn?
>
> There are exactly two calls of delete_insn that take the return value.
> One (delete_insn_and_edges) just uses it to return it itself (and there
Hi,
On Tue, 6 Dec 2011, Tom de Vries wrote:
> what should be the 'next' returned by delete_insn?
There are exactly two calls of delete_insn that take the return value.
One (delete_insn_and_edges) just uses it to return it itself (and there
are no calls to delete_insn_and_edges that use the re
On 05/12/11 13:50, Michael Matz wrote:
> Hi,
>
> On Sun, 4 Dec 2011, Eric Botcazou wrote:
>
>>> I'm just a bit worried about the name "delete_label". "delete_insn
>>> (label)" should always do the right thing for a pure deletion; the
>>> point of the new routine is that it also moves instructio
Hi,
On Sun, 4 Dec 2011, Eric Botcazou wrote:
> > I'm just a bit worried about the name "delete_label". "delete_insn
> > (label)" should always do the right thing for a pure deletion; the
> > point of the new routine is that it also moves instructions.
>
> It only fixes things up though, so tha
> Looks good codewise.
Seconded, modulo the file: the function should be in cfgrtl.c instead.
> I'm just a bit worried about the name "delete_label".
> "delete_insn (label)" should always do the right thing for a pure deletion;
> the point of the new routine is that it also moves instructions.
Tom de Vries writes:
> OK, factored out delete_label now.
>
> Bootstrapped and reg-tested on x86_64.
>
> Ok for next stage1?
Looks good codewise. I'm just a bit worried about the name "delete_label".
"delete_insn (label)" should always do the right thing for a pure deletion;
the point of the new
On 02/12/11 11:40, Richard Sandiford wrote:
> Tom de Vries writes:
>> On 27/11/11 23:59, Eric Botcazou wrote:
No, DELETED_LABEL notes still work just fine. It depends on how you
remove the label and replace it with a note, and Tom isn't showing
what he did, so...
>>>
>>> I agree tha
Tom de Vries writes:
> On 27/11/11 23:59, Eric Botcazou wrote:
>>> No, DELETED_LABEL notes still work just fine. It depends on how you
>>> remove the label and replace it with a note, and Tom isn't showing
>>> what he did, so...
>>
>> I agree that there is no obvious reason why just calling delet
On 27/11/11 23:59, Eric Botcazou wrote:
>> No, DELETED_LABEL notes still work just fine. It depends on how you
>> remove the label and replace it with a note, and Tom isn't showing
>> what he did, so...
>
> I agree that there is no obvious reason why just calling delete_insn would
> not
> work,
> No, DELETED_LABEL notes still work just fine. It depends on how you
> remove the label and replace it with a note, and Tom isn't showing
> what he did, so...
I agree that there is no obvious reason why just calling delete_insn would not
work, so this should be investigated first.
--
Eric Botc
On 25/11/11 14:05, Steven Bosscher wrote:
> On Fri, Nov 25, 2011 at 2:03 PM, Michael Matz wrote:
>> Hi,
>>
>> On Fri, 25 Nov 2011, Tom de Vries wrote:
>>
Note that you actually can remove labels also if they are
!can_delete_label_p, if you use delete_insn (which you do). It will
re
On Fri, Nov 25, 2011 at 2:03 PM, Michael Matz wrote:
> Hi,
>
> On Fri, 25 Nov 2011, Tom de Vries wrote:
>
>> > Note that you actually can remove labels also if they are
>> > !can_delete_label_p, if you use delete_insn (which you do). It will
>> > replace such undeletable labels by a DELETED_LABEL
Hi,
On Fri, 25 Nov 2011, Tom de Vries wrote:
> > Note that you actually can remove labels also if they are
> > !can_delete_label_p, if you use delete_insn (which you do). It will
> > replace such undeletable labels by a DELETED_LABEL note.
>
> I tried that as well but ran into these errors in
On 21/11/11 17:13, Michael Matz wrote:
> Hi,
>
> On Sat, 19 Nov 2011, Tom de Vries wrote:
>
>> On 11/18/2011 10:29 PM, Eric Botcazou wrote:
For the test-case of PR50764, a dead label is introduced by
fixup_reorder_chain in cfg_layout_finalize, called from
pass_reorder_blocks.
>>>
>
Hi,
On Sat, 19 Nov 2011, Tom de Vries wrote:
> On 11/18/2011 10:29 PM, Eric Botcazou wrote:
> >> For the test-case of PR50764, a dead label is introduced by
> >> fixup_reorder_chain in cfg_layout_finalize, called from
> >> pass_reorder_blocks.
> >
> > I presume that there is no reasonable way of
On 11/18/2011 10:29 PM, Eric Botcazou wrote:
>> For the test-case of PR50764, a dead label is introduced by
>> fixup_reorder_chain in cfg_layout_finalize, called from
>> pass_reorder_blocks.
>
> I presume that there is no reasonable way of preventing fixup_reorder_chain
> from introducing it or o
> For the test-case of PR50764, a dead label is introduced by
> fixup_reorder_chain in cfg_layout_finalize, called from
> pass_reorder_blocks.
I presume that there is no reasonable way of preventing fixup_reorder_chain
from introducing it or of teaching fixup_reorder_chain to remove it?
--
Eric
On 11/18/2011 09:16 PM, Andrew Pinski wrote:
> On Fri, Nov 18, 2011 at 5:11 AM, Tom de Vries wrote:
>> Hi Eric,
>>
>> this patch fixes an inefficiency problem I observed while working on PR50764.
>>
>> For the test-case of PR50764, a dead label is introduced by
>> fixup_reorder_chain
>> in cfg_la
On Fri, Nov 18, 2011 at 5:11 AM, Tom de Vries wrote:
> Hi Eric,
>
> this patch fixes an inefficiency problem I observed while working on PR50764.
>
> For the test-case of PR50764, a dead label is introduced by
> fixup_reorder_chain
> in cfg_layout_finalize, called from pass_reorder_blocks.
> The
Hi Eric,
this patch fixes an inefficiency problem I observed while working on PR50764.
For the test-case of PR50764, a dead label is introduced by fixup_reorder_chain
in cfg_layout_finalize, called from pass_reorder_blocks.
The dead label is removed by a cleanup_cfg in pass_duplicate_computed_got
22 matches
Mail list logo
