<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On first glance, this looks like it
should be handled by ForwardSwitchConditionToPHI in SimplifyCFG.
(Note: That's a guess. I'm reading the code for the first time.)
I'd suggest filling a bug with all of the options you're running
with. We really should catch this case.<br>
<br>
Well, really there's two missed optimization cases here. Even
without the case value forwarding, label_case2 and label_case3 are
redundant. <br>
<br>
Philip<br>
<br>
On 12/20/13 6:33 AM, Paweł Bylica wrote:<br>
</div>
<blockquote
cite="mid:CAE7VtSfA=fy2VpwRmYzjj=7wg9YUgkwEZEuGQXgF_+Gg7dF0jw@mail.gmail.com"
type="cite">
<div dir="ltr">Hello there,
<div><br>
</div>
<div>I have a high level code which would look like that in C++:</div>
<div><br>
</div>
<div>
<div><font face="courier new, monospace">enum E { A, B, C };</font></div>
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">E int2e(long i) {</font></div>
<div><font face="courier new, monospace"> switch(i) {</font></div>
<div><font face="courier new, monospace"> case 0:
return A;</font></div>
<div><font face="courier new, monospace"> case 1:
return B;</font></div>
<div><font face="courier new, monospace"> case 2:
return C;</font></div>
<div><font face="courier new, monospace"> default:
return A;</font></div>
<div><font face="courier new, monospace"> }</font></div>
<div><font face="courier new, monospace">}</font></div>
</div>
<div><br>
</div>
<div>It is compiled to this IR with O3 optimization:</div>
<div><br>
</div>
<div>
<div><font face="courier new, monospace">define i64 @int2e(i64
%i_arg) #0 {</font></div>
<div><font face="courier new, monospace">entry:</font></div>
<div><font face="courier new, monospace"> switch i64 %i_arg,
label %label_case1 [</font></div>
<div><font face="courier new, monospace"> i64 2, label
%label_case3</font></div>
<div><font face="courier new, monospace"> i64 1, label
%label_case2</font></div>
<div><font face="courier new, monospace"> ]</font></div>
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">label_case1:
; preds = %entry,
%label_case3, %label_case2</font></div>
<div><font face="courier new, monospace"> %merge = phi i64 [
%i_arg, %label_case2 ], [ %i_arg, %label_case3 ], [ 0,
%entry ]</font></div>
<div><font face="courier new, monospace"> ret i64 %merge</font></div>
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">label_case2:
; preds = %entry</font></div>
<div><font face="courier new, monospace"> br label
%label_case1</font></div>
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">label_case3:
; preds = %entry</font></div>
<div><font face="courier new, monospace"> br label
%label_case1</font></div>
<div><font face="courier new, monospace">}</font></div>
</div>
<div><br>
</div>
<div>In the result IR `phi` instruction has 3 branches, but two
first of them returns the same value. Shouln't it be
optimized?</div>
<div><br>
</div>
<div>- Paweł</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>