> Updated patch attached, tested on powerpc64-unknown-linux-gnu.
> This is exactly the same patch as before, except that it now uses
> "cleanup_cfg (0)" instead of delete_unreachable_blocks.
>
> OK for trunk?
OK if you adjust the ChangeLog as well, thanks.
--
Eric Botcazou
On Tue, Aug 28, 2012 at 11:54 PM, Eric Botcazou wrote:
>> The CLEANUP_CFG_CHANGED path looks unnecessary, it looks like this is
>> mostly for repairing loops but I don't see a reason for this in
>> postreload (loops have been freed at that point). I could do
>> cleanup_cfg(0) but there shouldn't be
> The CLEANUP_CFG_CHANGED path looks unnecessary, it looks like this is
> mostly for repairing loops but I don't see a reason for this in
> postreload (loops have been freed at that point). I could do
> cleanup_cfg(0) but there shouldn't be much to clean up other than
> unreachable blocks. I see de
On Mon, Aug 27, 2012 at 10:32 PM, Eric Botcazou wrote:
>> This patch fixes the problem by deleting unreachable basic blocks if
>> edges were purged during a reload-cse transformation on an insn. I
>> didn't add a test case because reliably triggering problems this late
>> in the pass pipeline is s
> This patch fixes the problem by deleting unreachable basic blocks if
> edges were purged during a reload-cse transformation on an insn. I
> didn't add a test case because reliably triggering problems this late
> in the pass pipeline is so hard.
A pervasive idiom in the RTL land is to call cleanu
Hello,
With my patch to visit insns in topological order in
init_alias_analysis, an issue in postreload-cse got exposed: Blocks
may become unreachable between calls of reload_cse_regs_1 but no CFG
cleanups are scheduled between them, resulting in an ICE in
pre_and_rev_post_order_compute at an asse
