<div dir="ltr">Having thought about this, I think this is safe for 3.6. Thanks Hans.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 10, 2015 at 5:21 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Feb 9, 2015 at 7:00 PM, Duncan P. N. Exon Smith<br>
<<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
> Thanks for the quick fix!<br>
><br>
>> On 2015-Feb-09, at 18:25, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br>
>><br>
>> Author: chandlerc<br>
>> Date: Mon Feb  9 20:25:56 2015<br>
>> New Revision: 228656<br>
>><br>
>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=228656&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=228656&view=rev</a><br>
>> Log:<br>
>> [x86] Fix PR22524: the DAG combiner was incorrectly handling illegal<br>
>> nodes when folding bitcasts of constants.<br>
>><br>
>> We can't fold things and then check after-the-fact whether it was legal.<br>
>> Once we have formed the DAG node, arbitrary other nodes may have been<br>
>> collapsed to it. There is no easy way to go back. Instead, we need to<br>
>> test for the specific folding cases we're interested in and ensure those<br>
>> are legal first.<br>
>><br>
>> This could in theory make this less powerful for bitcasting from an<br>
>> integer to some vector type, but AFAICT, that can't actually happen in<br>
>> the SDAG so its fine. Now, we *only* whitelist specific int->fp and<br>
>> fp->int bitcasts for post-legalization folding. I've added the test case<br>
>> from the PR.<br>
>><br>
>> (Also as a note, this does not appear to be in 3.6, no backport needed)<br>
><br>
> @Hans: I think Chandler was relying on my bisection from the PR here, but<br>
> I had only bisected the opt+llc.ll case.  (I first tried to bisect the<br>
> llc.ll case, but couldn't find a passing revision.)<br>
><br>
> I've just checked the llc.ll case on 3.6 (well, slightly old r228165) and<br>
> it *does* repro, and cherry-picking this commit fixes it.<br>
><br>
> Probably not *urgent*, since -instcombine isn't exposing it, but still<br>
> seems like a good fix.<br>
<br>
</div></div>I'm okay with merging this if Chandler thinks the patch is safe.<br>
<span class="HOEnZb"><font color="#888888"><br>
 - Hans<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>