[cfe-dev] is opencl-style select function supported?

[nate begeman]

On Sep 21, 2010, at 11:05 AM, Jochen Wilhelmy wrote:

> On 21.09.2010 19:15, Nate Begeman wrote:
>> On Sep 21, 2010, at 1:20 AM, Jochen Wilhelmy wrote:
>> 
>>   
>>> On 21.09.2010 00:43, Nate Begeman wrote:
>>>     
>>>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100920/034760.html
>>>> 
>>>> On Sep 20, 2010, at 10:51 AM, Nate Begeman wrote:
>>>> 
>>>> 
>>>>       
>>> thanks for solving this problem fast, but i wonder why you do something like
>>> result = c&  a | ~c&  a
>>> instead of using the llvm select instruction, i.e.
>>> Builder.CreateSelect(TestMSB, LHS, RHS, "select");
>>>     
>> I don't think the LLVM IR select instruction has the appropriate semantics for vectors, but I could be wrong.  Doing a bitselect/blend (whatever your preferred terminology) allows the target code generators to avoid having to see<4 x i1>.
>>   
> the llvm documentation says that select works on vectors:
> http://www.llvm.org/docs/LangRef.html#i_select
> 
> for me select is better than bitselect/blend since I analyze the llvm ir and therefore it is more convenient if the
> instructions are highlevel.

I don't think it would be too hard to find bit-select in the IR, but this is the behavior specified by OpenCL, since that's what actually works well on most SIMD architectures.  The vector compare + vector sext pattern is the current magic required to get SelectionDAGISel to generate something type legal and appropriate for SSE and AltiVec comparison operations. 

> 
>>   
>>> 
>>> I also would suggest that this depends on the Altivec option instead of
>>> OpenCL.
>>> I'd like to use vectors with C++ and therefore enable Altivec. Then I
>>> would expect
>>> the vectorized ? : operator to work.
>>>     
>> I'm not the right person to comment on if that's appropriate or not.  I don't see a problem per se with enabling this for altivec+ext_vector_type but I'll let some other language person decide :)
>>   
> Have you already asked this person or can you tell me who it is ? ;-)

I dunno who maintains C-ish stuff like this, but I think Doug Gregor or John McCall could probably weigh in.

Nate