Hi,
hit by a bug in llvm 2.8, I was wondering if there are any stable
release branches? The bug is only present in the release branch, and I
have a fix for it (see attachment). IMHO the bug is quite bad, and
workarounds are actually ugly and generate inefficient code (couldn't
really come up with anything which actually generated correct code which
didn't require at least a pshufb).
For reference, this is the bug in question:
http://llvm.org/bugs/show_bug.cgi?id=8381
Here's also a short example:
define <8 x i16> @broadcast_16(<8 x i16> %var1, <8 x i16>
%var2) {
entry:
%0 = shufflevector <8 x i16> %var2, <8 x i16> undef, <8 x
i32>
zeroinitializer
ret <8 x i16> %0
}
Which miscompiles badly to
punpcklwd %xmm0, %xmm1
pshufd $0, %xmm1, %xmm0
ret
(This happens for all similar broadcast shuffles, except if the reg
containing the vector to shuffle happens to be xmm0 just by luck).
Roland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shuf_fix.diff
Type: text/x-patch
Size: 837 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101028/67112e04/attachment.bin>
On Oct 28, 2010, at 7:30 AM, Roland Scheidegger wrote:> Hi, > > hit by a bug in llvm 2.8, I was wondering if there are any stable > release branches? The bug is only present in the release branch, and I > have a fix for it (see attachment). IMHO the bug is quite bad, and > workarounds are actually ugly and generate inefficient code (couldn't > really come up with anything which actually generated correct code which > didn't require at least a pshufb).We have never done "dot" releases off the branch, but there is nothing that prevents doing it in the future, we just need someone to step up to be the release manager for the branch, define policies around what goes in, etc. -Chris
On Oct 28, 2010, at 9:05 AM, Chris Lattner wrote:> On Oct 28, 2010, at 7:30 AM, Roland Scheidegger wrote: > >> Hi, >> >> hit by a bug in llvm 2.8, I was wondering if there are any stable >> release branches? The bug is only present in the release branch, and I >> have a fix for it (see attachment). IMHO the bug is quite bad, and >> workarounds are actually ugly and generate inefficient code (couldn't >> really come up with anything which actually generated correct code which >> didn't require at least a pshufb). > > We have never done "dot" releases off the branch, but there is nothing that prevents doing it in the future, we just need someone to step up to be the release manager for the branch, define policies around what goes in, etc. >The first step is to see if we still have testers available for the dot release. :-) I sent an email out to the 2.8 release team asking if they're available for a dot release. I will work with them to see if a dot release is a feasible option for us. -bw