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 instead we recognize this case and > remove the BARRIER appropriately, all the cruft just disappears.
I suppose with "cruft" you mean the dead end in the CFG due to builtin_unreachable, correct? If so, then I suppose you could also just let cfgcleanup handle that cruft and not wait until if-conversion. It still puzzles me what exactly the semantics __builtin_unreachable are, but AFAIU, a basic block ending in __builtin_unreachable could go anywhere (undefined behavior). So why do we emit a BARRIER after then to begin with? Or why not even drop __builtin_unreachable completely during expand? (It's caused me quite a lot of pain already: __builtin_unreachable in the middle of a basic block confuses find_many_sub_basic_blocks, there's a PR somewhere with my name on it...). Hacking BARRIERs by hand in a function that's supposed to know about the CFG just seems wrong :-( Ciao! Steven
