PR18102, PATCH + test: wrong code on x86_64-linux-gnu (affecting trunk and 3.3)

Manman Ren manman.ren at gmail.com
Wed Jan 15 11:48:42 PST 2014


Nits:

-    return LHS.OffsetFromBase < RHS.OffsetFromBase;
+    if (LHS.OffsetFromBase < RHS.OffsetFromBase)
+      return true;
+    if (LHS.OffsetFromBase == RHS.OffsetFromBase)
+      return LHS.SequenceNum > RHS.SequenceNum;
+    return false;

return (LHS.OffsetFromBase < RHS.OffsetFromBase) || (LHS.OffsetFromBase ==
RHS.OffsetFromBase && LHS.SequenceNum > RHS.SequenceNum); ?

+; Function Attrs: nounwind uwtable
+; CHECK-LABEL: f
+define void @f() {
+entry:

remove "Function Attrs"?

Thanks,
Manman



On Wed, Jan 15, 2014 at 7:04 AM, Stepan Dyatkovskiy <stpworld at narod.ru>wrote:

> Fixed test
>
> Stepan Dyatkovskiy wrote:
>
>> Hi all.
>>
>> I think, trouble was in DAGCombiner::MergeConsequtiveStores.
>>
>> Consider, how it works for next example:
>>
>> store i8 1, a[0]
>> store i8 2, a[1]
>> store i8 3, a[1]   ; a[1] again.
>> return   ; DAG starts here
>>
>> 1. Method will collect all the 3 stores.
>> 2. It sorts them by distance from the base pointer (farthest with
>> highest index).
>> 3. It takes first consecutive non-overlapping stores and (if possible)
>> replaces them with a single store instruction.
>>
>> The point is, we can't determine here which 'store' instruction
>> would be the second after sorting ('store 2' or 'store 3').
>> It happens that 'store 3' would be the second, and 'store 2' would be
>> the third.
>>
>> So after merging we have the next result:
>>
>> store i16 (1 | 3 << 8), base   ; is a[0] but bit-casted to i16
>> store i8 2, a[1]
>>
>> So actually we swapped 'store 3' and 'store 2' and got wrong contents in
>> a[1].
>>
>> Fix: In sort routine just also take into account mem-op sequence number.
>>
>> -Stepan
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140115/14bc155d/attachment.html>


More information about the llvm-commits mailing list