llvm dev - Jun 2008 - [LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86

Hi all,

 

When trying to generate a VFCmp instruction when UnsafeFPMath is set to true
I get an assert "Unexpected CondCode" on my x86 system. This also
happens
with UnsafeFPMath set to false and using an unordered compare. Could someone
look into this?

 

While I'm at it, is there any reason why only the most significant bit of
the return value of VFCmp is defined (according to the documentation)? Both
AltiVec and SSE set the components of the result to either all 1's or all
0's. Having only the most significant bit doesn't seem useful to me at
all,
and (arithmetic) shifting vectors to replicate the bit isn't supported.

 

Thanks!

 

Nicolas Capens

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080613/3831507d/attachment.html>

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote:
> Hi all,
>
> When trying to generate a VFCmp instruction when UnsafeFPMath is set  
> to true I get an assert “Unexpected CondCode” on my x86 system. This  
> also happens with UnsafeFPMath set to false and using an unordered  
> compare. Could someone look into this?
Have you filed a bug?
>
> While I’m at it, is there any reason why only the most significant  
> bit of the return value of VFCmp is defined (according to the  
> documentation)? Both AltiVec and SSE set the components of the  
> result to either all 1’s or all 0’s. Having only the most  
> significant bit doesn’t seem useful to me at all, and (arithmetic)  
> shifting vectors to replicate the bit isn’t supported.
Nate can probably explain this better than anyone.

Evan
>
> Thanks!
>
> Nicolas Capens
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080613/59c08b15/attachment.html>

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote:
> Hi all,
>
> When trying to generate a VFCmp instruction when UnsafeFPMath is set  
> to true I get an assert “Unexpected CondCode” on my x86 system. This  
> also happens with UnsafeFPMath set to false and using an unordered  
> compare. Could someone look into this?
Please provide a testcase.
>
> While I’m at it, is there any reason why only the most significant  
> bit of the return value of VFCmp is defined (according to the  
> documentation)? Both AltiVec and SSE set the components of the  
> result to either all 1’s or all 0’s. Having only the most  
> significant bit doesn’t seem useful to me at all, and (arithmetic)  
> shifting vectors to replicate the bit isn’t supported.
LLVM is intended to support other vector instruction sets, including  
SPU, Alpha, etc.  The commonality was that the MSB is set, and we  
would like to add support for vector shifting at some point.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080613/23ece5c5/attachment.html>

Hi Evan,

 

No, I haven't filed a bug. I'd first like someone to confirm this
behavior.
Anyway, I'll post some test code in a minute.

 

Can I contact Nate directly about the definition of VFCmp?

 

Thanks,

 

Nicolas

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Evan Cheng
Sent: Saturday, 14 June, 2008 01:04
To: LLVM Developers Mailing List
Cc: Nate Begeman
Subject: Re: [LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86

 

 

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote:





Hi all,

 

When trying to generate a VFCmp instruction when UnsafeFPMath is set to true
I get an assert "Unexpected CondCode" on my x86 system. This also
happens
with UnsafeFPMath set to false and using an unordered compare. Could someone
look into this?

 

Have you filed a bug?





 

While I'm at it, is there any reason why only the most significant bit of
the return value of VFCmp is defined (according to the documentation)? Both
AltiVec and SSE set the components of the result to either all 1's or all
0's. Having only the most significant bit doesn't seem useful to me at
all,
and (arithmetic) shifting vectors to replicate the bit isn't supported.

 

Nate can probably explain this better than anyone.

 

Evan





 

Thanks!

 

Nicolas Capens

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080616/41dbe658/attachment.html>

Hi Chris,

 

I've attached a replacement of fibonacci.cpp that reproduces the issue on
x86/SSE systems.

 

Regarding the definition of the VFCmp instruction, I think it would really
be a lot more valuable to define it as returning all 1's or all 0's per
element. Just setting the most significant bit is pretty much worthless
(someone correct me if I'm wrong). I checked and I couldn't actually
find
any instruction set that only sets the MSB when comparing vectors, except by
actually doing just a subtract. Since people need full masks before they can
do anything useful with it (requiring a shift or conditional replace) I was
thinking why not make that part of VFCmp? Note that this change in VFCmp's
definition won't break compatibility.

 

Kind regards,

 

Nicolas

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Chris Lattner
Sent: Saturday, 14 June, 2008 02:40
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86

 

 

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote:





Hi all,

 

When trying to generate a VFCmp instruction when UnsafeFPMath is set to true
I get an assert "Unexpected CondCode" on my x86 system. This also
happens
with UnsafeFPMath set to false and using an unordered compare. Could someone
look into this?

 

Please provide a testcase.





 

While I'm at it, is there any reason why only the most significant bit of
the return value of VFCmp is defined (according to the documentation)? Both
AltiVec and SSE set the components of the result to either all 1's or all
0's. Having only the most significant bit doesn't seem useful to me at
all,
and (arithmetic) shifting vectors to replicate the bit isn't supported.

 

LLVM is intended to support other vector instruction sets, including SPU,
Alpha, etc.  The commonality was that the MSB is set, and we would like to
add support for vector shifting at some point.

 

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080616/3250cb08/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fibonacci.cpp
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080616/3250cb08/attachment.ksh>

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote:
> Hi all,
>
> When trying to generate a VFCmp instruction when UnsafeFPMath is set  
> to true I get an assert “Unexpected CondCode” on my x86 system. This  
> also happens with UnsafeFPMath set to false and using an unordered  
> compare. Could someone look into this?
>
> While I’m at it, is there any reason why only the most significant  
> bit of the return value of VFCmp is defined (according to the  
> documentation)? Both AltiVec and SSE set the components of the  
> result to either all 1’s or all 0’s. Having only the most  
> significant bit doesn’t seem useful to me at all, and (arithmetic)  
> shifting vectors to replicate the bit isn’t supported.
There are other architectures which don't do this, so defining it as  
such would over-constrain the problem.  The bits are undefined, and  
may be set to any value by the target arch.   The goal here is that  
you can essentially treat each element of the vector as a signed  
integer and select (or other operation) if the value is less than  
zero, rather than specifically equal to -1.  This matches things like  
SSE's blend and PPC's fsel.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080616/78fc9de1/attachment.html>

Hi Nate!

 

I don't see how that would work. Select doesn't work per element.

 

Say we're trying to vectorize the following C++ code:

 

if(v[0] < 0) v[0] += 1.0f;

if(v[1] < 0) v[1] += 1.0f;

if(v[2] < 0) v[2] += 1.0f;

if(v[3] < 0) v[3] += 1.0f;

 

With SSE assembly this would be as simple as:

 

movaps xmm1, xmm0   // v in xmm0

cmpltps xmm1, zero       // zero = {0.0f, 0.0f, 0.0f, 0.0f}

andps xmm1, one            // one = {1.0f, 1.0f, 1.0f, 1.0f} 

addps xmm0, xmm1

 

With the current definition of VFCmp this seems hard if not impossible to
achieve. Vector compare instructions that  return all 1's or all 0's per
element are very common, and they are quite powerful in my opinion
(effectively allowing to implement a per-element Select). It seems to me
that for the few architectures that don't have such instructions it would be
useful to have LLVM generate a short sequence of instructions that does
result in useful masks of all 1's or all 0's. Or am I missing something?

 

Thanks a lot,

 

Nicolas

 

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Nate Begeman
Sent: Monday, 16 June, 2008 22:43
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86

 

 

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote:





Hi all,

 

When trying to generate a VFCmp instruction when UnsafeFPMath is set to true
I get an assert "Unexpected CondCode" on my x86 system. This also
happens
with UnsafeFPMath set to false and using an unordered compare. Could someone
look into this?

 

While I'm at it, is there any reason why only the most significant bit of
the return value of VFCmp is defined (according to the documentation)? Both
AltiVec and SSE set the components of the result to either all 1's or all
0's. Having only the most significant bit doesn't seem useful to me at
all,
and (arithmetic) shifting vectors to replicate the bit isn't supported.

 

There are other architectures which don't do this, so defining it as such
would over-constrain the problem.  The bits are undefined, and may be set to
any value by the target arch.   The goal here is that you can essentially
treat each element of the vector as a signed integer and select (or other
operation) if the value is less than zero, rather than specifically equal to
-1.  This matches things like SSE's blend and PPC's fsel.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080617/fdd316ee/attachment.html>