[cfe-dev] Patch to add __builtin_shufflevector

[Chris Lattner]

On Feb 28, 2008, at 9:18 PM, Eli Friedman wrote:
>> This should probably also come in const form.  It would be nice to
>> have an "int getShuffleMaskIdx(unsigned N)" method that converts the
>> shuffle mask AST to a constant int and returns it, as a helper  
>> function.
>
> Fine.  Although it's probably worth asking, how wide are vectors  
> allowed to be?

Arbitrary in theory, in practice, vectors of up to 256 are interesting  
I guess, but 16 and less are used in practice.

>>        if (FunctionDecl *FDecl = dyn_cast<FunctionDecl>(DRExpr-
>>> getDecl())) {
>> +        ExprResult R = CheckFunctionCall(FDecl, TheCall.take());
>>          if (R.error) return;
>>          TheCall = R.Val;
>>        }
>
> Hmm? I'm not quite following this bit... the current model is that if
> we end up in CheckFunctionCall, it gets ownership of the call pointer
> (because we call take), and then it either returns it or deletes it.
> What exactly is the model you're suggesting?

Ooooh, I completely missed the .take() there.  If you think this is  
the best way to go then your code is exactly right, sorry for the  
oversight!

>> +  if (!Context.typesAreCompatible(
>> +          TheCall->getArg(0)->getType().getUnqualifiedType(),
>> +          TheCall->getArg(1)->getType().getUnqualifiedType())) {
>> +    return Diag(TheCall->getLocEnd(),
>> diag::err_typecheck_call_too_few_args);
>> +  }
>>
>> I think the (canonical) types should be required to be exactly
>> identical, not just compatible, what do you think?
>
> The two aren't different in any substantial way, as far as I can  
> tell, but okay.

Fair enough, checking for type equality makes it more explicit what  
you mean though.

>> As a random thought, it would be relatively easy to make
>> __builtin_shufflevector also support: __builtin_shufflevector(Vec,
>> idx1, idx2, idx3, idx4) - a shuffle with a single vector (implicitly
>> making the second vector be undef).  I think this would be handy, but
>> is jsut syntactic sugar and may not be worth it.  What do you think?
>
> I don't think it's worth bothering with... you can always just do
> __builtin_shufflevector(Vec, Vec, ...), and adding that would
> significantly complicate the typechecking.  If it turns out to have
> significant uses, we can consider adding it.

Great point, lets wait until there is a client for it.

Thanks again Eli,

-Chris