[Bug rtl-optimization/17234] if-conversion bug on x86

roger at eyesopen dot com gcc-bugzilla@gcc.gnu.org
Sun Sep 5 00:50:00 GMT 2004


------- Additional Comments From roger at eyesopen dot com  2004-09-05 00:50 -------
This transformation is internally known as IF-CASE-1 and is performed during
the second if-conversion pass, .20.ce2.  From the CFG perspective this change
appears to be a win (at the point it is performed); by speculatively executing
a single instruction we reduce the CFG from four basic blocks to just three.

i.e.     0        0'
        / \       | \
       1   2  =>  |  2
        \ /       | /
         3        3

Normally, this simplification reduces the of unconditional branches in the
code, and allows for improved basic block reordering optimizations.
Unfortunately, in this case, basic block 3 marks the end of the function,
and we subsequently duplicate the function epilogue.  This later duplication
ends up turning both forms of the above CGF into 3 basic blocks, but the
if-conversion has pessimized the code with a partially dead assignment in
0' that could have remained in 3' (in the diagram below, reflecting the final CFG).

i.e.     0           0'
        / \    =>   / \
      1+3 2+3      3'  2+3

One solution may be to disable IF-CASE-1 is the join block is the last
basic block in the function, contains no additional instructions, and we're
expecting to duplicate the epilogue.

Jan, what do you think?  Is there an easy way to determine if the join block
of an IF-THEN-ELSE is a candidate for basic block duplication?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234



More information about the Gcc-bugs mailing list