[llvm] r225597 - X86: Properly decode shuffle masks when the constant pool type is weird

[David Majnemer]

On Sat, Jan 10, 2015 at 11:09 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Sat, Jan 10, 2015 at 9:08 PM, David Majnemer <david.majnemer at gmail.com>
> wrote:
>
>> -  assert((NumElements == 16 || NumElements == 32) &&
>> -         "Only 128-bit and 256-bit vectors supported!");
>> +  if (!DestTy)
>> +    return;
>> +
>> +  if (DestTy != MaskTy) {
>> +    if (!CastInst::castIsValid(Instruction::BitCast, const_cast<Constant
>> *>(C),
>> +                               DestTy))
>> +      return;
>> +
>> +    C = ConstantFoldInstOperands(Instruction::BitCast, DestTy,
>> +                                 const_cast<Constant *>(C), TD);
>> +    MaskTy = DestTy;
>> +  }
>>
>
> No no no, you don't get to play fast and loose by constant folding here. =]
>
> You may not have a module, your context may be very different than you
> expect. =/
>
> I would just do the bit math manually.
>

I've reverted the parts that cause the build bots to get upset in r225599.

As discussed on IRC, this code is only used in the code-generating parts of
LLVM, we will always have a Module, etc.  However, those who which to link
with this micro-library might not have the target specific constant folder.

Strangely, the CMake build is fine with where the code was living while the
autoconf build failed to link the MC unittest.  I've got a feeling that the
link dependencies have diverged somewhere.

Regardless, I think the right thing to do is to take this code (with it's
use of the target-specific constant folder) and move it to a more relevant
place in the X86 backend.  The question is where?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150110/b189417b/attachment.html>