[PATCH][X86] Fix for a a poor code generation bug affecting addss/mulss and other SSE scalar fp arithmetic instructions

[Jim Grosbach]

Agreed. With that addition, this all LGTM. Thanks for the patch!

-Jim

On Dec 9, 2013, at 12:56 PM, Nadav Rotem <nrotem at apple.com> wrote:

> Hi Andrea, 
> 
> Thanks for the quick fix.  Can you please add comments above the patterns that explain the problems that you are solving with these patterns?  
> 
> Thanks,
> Nadav
> 
> On Dec 9, 2013, at 12:53 PM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote:
> 
>> Sorry for sending a new patch, however I just realized that my last
>> patch could be improved introducing more generic patterns to also
>> match the case where not all the operands of a scalar floating point
>> arithmetic instruction are generated by a 'extract_vector_elt'.
>> 
>> Example:
>> 
>> define <4 x float> @foo(<4 x float> %a, <4 x float> %b) {
>> %1 = extractelement <4 x float> %b, i32 0
>> %2 = extractelement <4 x float> %a, i32 0
>> %3 = fadd float %1, %2
>> %4 = fadd float %2, %3
>> %result = insertelement <4 x float> %a, %4, i32 0
>> }
>> 
>> Should generate:
>> addss %xmm0, %xmm1
>> addss %xmm1, %xmm0
>> ret
>> 
>> The new patch in attachment introduces more test cases and also adds
>> explicit CHECK-NOT to verify that we don't generate redundant inserts.
>> 
>> Please let me know what do you think.
>> 
>> Thanks,
>> Andrea Di Biagio
>> 
>> On Mon, Dec 9, 2013 at 3:35 PM, Andrea Di Biagio
>> <andrea.dibiagio at gmail.com> wrote:
>>> Hi Jim,
>>> I  fixed the problem as you suggested by simply adding new patterns
>>> and I have attached a new version of the patch.
>>> Please let me know what do you think and if it is ok to submit.
>>> 
>>> Thanks,
>>> Andrea Di Biagio
>>> 
>>> 
>>> On Sat, Dec 7, 2013 at 10:31 AM, Andrea Di Biagio
>>> <andrea.dibiagio at gmail.com> wrote:
>>>> Hi Jim,
>>>> 
>>>> Thanks for the feedback!
>>>> I understand your concerns and I agree that adding new target ISD
>>>> nodes is not ideal.
>>>> I'll try to fix the problem as you suggested by simply adding new
>>>> patterns in X86InstrSSE.td and I'll send a new patch for review.
>>>> 
>>>> Thanks,
>>>> Andrea
>>>> 
>>>> On Fri, Dec 6, 2013 at 11:52 PM, Jim Grosbach <grosbach at apple.com> wrote:
>>>>> It won’t work to just recognize the insert directly in the patterns and avoid the DAGcombine entirely? I’d prefer to avoid adding extra target ISD nodes if we can help it. They inhibit optimization (other DAGcombines) and make other codegen patterns harder to generalize.
>>>>> 
>>>>> -Jim
>>>>> 
>>>>> On Dec 6, 2013, at 1:40 PM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> This patch fixes a poor code generation bug affecting SSE scalar fp
>>>>>> instructions like addss/mulss.
>>>>>> The problem has been originally reported here:
>>>>>> http://comments.gmane.org/gmane.comp.compilers.llvm.devel/68542
>>>>>> 
>>>>>> At the moment, the x86 backend tends to emit unnecessary vector insert
>>>>>> instructions immediately after sse scalar fp instructions.
>>>>>> 
>>>>>> Example:
>>>>>> /////////////////////////////////
>>>>>> __m128 foo(__m128 A, __m128 B) {
>>>>>> A[0] += B[0];
>>>>>> return A;
>>>>>> }
>>>>>> /////////////////////////////////
>>>>>> 
>>>>>> produces the following sequence:
>>>>>> addss  %xmm0, %xmm1
>>>>>> movss  %xmm1, %xmm0
>>>>>> 
>>>>>> Instead of:
>>>>>> addss %xmm1, %xmm0
>>>>>> 
>>>>>> This patch addresses the problem at ISel stage introducing a target
>>>>>> specific combine rule to fold patterns like this one:
>>>>>> 
>>>>>> a0 :     f32 = extract_vector_elt ( A, 0)
>>>>>> b0 :     f32 = extract_vector_elt ( B, 0)
>>>>>> r0 :     f32 = fadd a0, b0
>>>>>> result : v4f32 = insert_vector_elt ( A, r0, 0 )
>>>>>> 
>>>>>> into a single 'addss' instruction.
>>>>>> 
>>>>>> Please let me know what you think.
>>>>>> 
>>>>>> Thanks,
>>>>>> Andrea Di Biagio
>>>>>> SN Systems - Sony Computer Entertainment Group
>>>>>> <patch.diff>_______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>> 
>> <patch-v3.diff>
>