On 12/10/13 16:22, Steven Bosscher wrote:
On Tue, Dec 10, 2013 at 7:30 AM, Jeff Law wrote:
Ping!
I'd prefer going with the first patch to merge_if_blocks (with a big
"???" or FIXME), to contain this problem to where it occurs.
Otherwise, before you know it, there are other places in the compiler
that assume it's OK to merge blocks that are not can_merge_block_p.
I think the patch as posted in the RFA is better based on the robustness
principle. Nothing stops an RTL pass from asking for two blocks to be
merged when there's a BARRIER between them. So rtl_merge_blocks should
do the right thing when presented with that situation.
Furthermore, I do not believe that can_merge_blocks_p should reject
merging of blocks where there's a BARRIER between them. There is a very
legitimate use for that that arises from conditional execution and from
the use of __builtin_unreachable.
Obviously if you succeed in removing BARRIERS after 4.9, then all this
becomes moot. But as long as BARRIERS exist, we should handle them
properly.
Jeff
