[polly] r312446 - [ForwardOpTree] Fix typos. NFC.

Michael Kruse via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 3 11:48:51 PDT 2017


2017-09-03 20:03 GMT+02:00 Tobias Grosser <tobias.grosser at inf.ethz.ch>:
>
>
> On Sun, Sep 3, 2017, at 18:09, Michael Kruse via llvm-commits wrote:
>> Author: meinersbur
>> Date: Sun Sep  3 09:09:38 2017
>> New Revision: 312446
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=312446&view=rev
>> Log:
>> [ForwardOpTree] Fix typos. NFC.
>>
>> Modified:
>>     polly/trunk/lib/Transform/ForwardOpTree.cpp
>>
>> Modified: polly/trunk/lib/Transform/ForwardOpTree.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/polly/trunk/lib/Transform/ForwardOpTree.cpp?rev=312446&r1=312445&r2=312446&view=diff
>> ==============================================================================
>> --- polly/trunk/lib/Transform/ForwardOpTree.cpp (original)
>> +++ polly/trunk/lib/Transform/ForwardOpTree.cpp Sun Sep  3 09:09:38 2017
>> @@ -410,12 +410,12 @@ public:
>>      if (!LI)
>>        return FD_NotApplicable;
>>
>> -    // If the load is already in the statement, not forwarding is
>> necessary.
>> +    // If the load is already in the statement, no forwarding is
>> necessary.
>>      // However, it might happen that the LoadInst is already present in
>>      the
>
> should this read "is NOT YET present"?

"already present" is correct. Not yet present would be the standard case.

This happens if the load is in two operand tree, both wanting to
forward it. After processing the first operand tree, the LoadInst is
added to the stmt. Processing the first would add the same LoadInst a
second time.

That means the same LoadInst (with the same address) is present
_twice_ in the instruction list. getArrayAccessOrNULLFor() will
complain about two MemoryAccesses for the same LoadInst, as it cannot
differentiate which one we mean. That is, we can add only _one_
MemoryAccess which is used for _both_ LoadInst in the instruction
list.

-polly-simplify will then remove all but the first LoadInst from the
instruction list.

Michael


More information about the llvm-commits mailing list