On 11/27/13 00:57, Steven Bosscher wrote:
On Wed, Nov 27, 2013 at 6:47 AM, Jeff Law wrote:
How about rtl_merge_blocks getting smarter about removing BARRIERS between
the blocks-to-be-merged?
It'd be breaking away further from the rule that merge_blocks should
only work if can_merge_blocks.
(Bu
On Wed, Nov 27, 2013 at 6:47 AM, Jeff Law wrote:
> How about rtl_merge_blocks getting smarter about removing BARRIERS between
> the blocks-to-be-merged?
It'd be breaking away further from the rule that merge_blocks should
only work if can_merge_blocks.
(But that isn't enforced in cfgrtl mode right
On 11/26/13 15:44, Steven Bosscher wrote:
Open to other suggestions.
Can't claim to have any, at least not for short-term solutions.
How about rtl_merge_blocks getting smarter about removing BARRIERS
between the blocks-to-be-merged?
Something like this (untested, except for verifying it avoi
On 26 November 2013 22:05, Jeff Law wrote:
> Open to other suggestions. The fundamental issue is BARRIERs live outside
> the CFG. So a pass that thinks it can manipulate the CFG and ignore the
> underlying RTL are going to have problems with things like this.
Here, the barrier itself acts like
On 11/26/13 15:44, Steven Bosscher wrote:
So we have a block which calls fubar. The block would have no successors.
And I think we're right back in the same situation. We're going to have a
BARRIER after that block with no successors and ifcvt is going to muck
things up tripping the checking fa
On Tue, Nov 26, 2013 at 11:05 PM, Jeff Law wrote:
> On 11/26/13 14:41, Steven Bosscher wrote:
>>
>>
>> I suppose with "cruft" you mean the dead end in the CFG due to
>> builtin_unreachable, correct?
>
> Yes.
>
>
>
> > If so, then I suppose you could also
>>
>> just let cfgcleanup handle that cruft
On 11/26/13 14:41, Steven Bosscher wrote:
I suppose with "cruft" you mean the dead end in the CFG due to
builtin_unreachable, correct?
Yes.
If so, then I suppose you could also
just let cfgcleanup handle that cruft and not wait until
if-conversion.
But what does all this look like at the RTL
On Tue, Nov 26, 2013 at 10:03 PM, Jeff Law wrote:
>> I believe the proper fix would be to not recognize this as an
>> if-conversion block candidate in cond_exec_find_if_block.
>
> That's easy enough to do, but leaves a fair amount of useless cruft in the
> IL and ultimately the resulting code. If
On 11/26/13 13:30, Steven Bosscher wrote:
On Tue, Nov 26, 2013 at 8:20 PM, Jeff Law wrote:
The jump threading changes have exposed a latent bug on machines with
conditional execution such as the ARM.
Going into the last conditional execution pass we have:
[ ... ]
(insn 16 60 17 2 (set (reg:CC
On Tue, Nov 26, 2013 at 8:20 PM, Jeff Law wrote:
>
> The jump threading changes have exposed a latent bug on machines with
> conditional execution such as the ARM.
>
> Going into the last conditional execution pass we have:
>
> [ ... ]
> (insn 16 60 17 2 (set (reg:CC 100 cc)
> (compare:CC (
The jump threading changes have exposed a latent bug on machines with
conditional execution such as the ARM.
Going into the last conditional execution pass we have:
[ ... ]
(insn 16 60 17 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 1 r1 [121])
(const_int 0 [0]))) j.c:14 226
11 matches
Mail list logo
