r209489 - Fix a bug in xmmintrin.h.

[Akira Hatanaka]

If this was a fix for clang’s code (IR) generation or an llvm optimization, it would make sense to test the IR. I felt it was a little odd to test the IR for a fix in one of the header files, since the mistake doesn’t involve clang’s code-gen. 

If I were to write an IR test, I would probably check the string “_mm_packs_pi32”. I don’t know if this is possible, but wouldn’t it be better to somehow test the string “_mm_packs_pi32” in the source code (using clang -E)?

On May 22, 2014, at 9:29 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Thu, May 22, 2014 at 10:27 PM, Akira Hatanaka <ahatanaka at apple.com> wrote:
> I thought about adding a test case, but wasn’t sure how this fix should be tested.
> 
> I don’t think it’s a good idea to check the bitcode clang generates, is it?
> 
> We routinely test the generated IR (without optimizations)?
>  
> 
> On May 22, 2014, at 8:35 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> 
>> On Thu, May 22, 2014 at 6:38 PM, Akira Hatanaka <ahatanaka at apple.com> wrote:
>> Author: ahatanak
>> Date: Thu May 22 19:38:07 2014
>> New Revision: 209489
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=209489&view=rev
>> Log:
>> Fix a bug in xmmintrin.h.
>> 
>> The last step of _mm_cvtps_pi16 should use _mm_packs_pi32, which is a function
>> that reads two __m64 values and packs four 32-bit values into four 16-bit
>> values.
>> 
>> This (somewhat obviously) needs a test case.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140522/8c447248/attachment.html>