[llvm-dev] RFC phantom memory intrinsic

[Philip Reames via llvm-dev]

In many cases, we can resolve such cases via a speculative load. I 
assume you've reviewed the case at hand to ensure we can't speculative 
insert a wider load in the case you need?

That doesn't work for the store case, but if you just care about loads...

Philip


On 09/12/2017 12:54 AM, Dinar Temirbulatov via llvm-dev wrote:
> Hi,
> For PR21780 solution, I plan to add a new functionality to restore
> memory operations that was once deleted, in this particular case it is
> the load operations that were deleted by InstCombine, please note that
> once the load was removed there is no way to restore it back and that
> prevents us from vectorizing the shuffle operation. There are probably
> more similar issues where this approach could be applied.
> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that,
> indicating that for particular pointer let's call it %ptr we observed
> maximum possible offset at which there was reference by its type in a
> function. After InstCombine deleted the load operation, it could be
> restored in SLPVectorizer and we could restore chains of GEPs, Loads
> and Inserts in case we encounter phatom_mem intrinsic.
>
>   Here is two part review:
>            https://reviews.llvm.org/D37579 - InstCombine part.
>            https://reviews.llvm.org/D37648 - SLP part.
>
> Also, there might be different approaches in describing deleted memory
> operations, for example, for my case: phantom_load(llvm_anyptr_ty,
> llvm_i64_ty). First parameter describes pointer and second parameter
> offset from pointer this loaded was deleted, for example. This two
> operations:
>
>    %arrayidx1 = getelementptr inbounds double, double* %ptr, i64 1
>    %ld1 = load double, double* %arrayidx1
>
> could be represented in the IR with this one: "void phantom_load(%ptr,
> 1)" after removal. But, the approach that is already implemented in
> both reviews looks better to me since we don't need to add intrinsic
> for every removed operation in the IR. Also, while constructing such
> form in the IR we have to be careful since some pointer operations
> might be in loops and as the result we might end up construction an
> incorrect IR.  So, I just avoid to notice any pointer operation if it
> is belong to a loop, except those where the the whole chain of
> operations pointer origin, GEP, Load, Shuffle operation are in the
> same loop and in the same basic block.
>                                           Thanks, Dinar.
>
> Here is the thread for this issue regarding using metadata:
> http://lists.llvm.org/pipermail/llvm-dev/2017-July/115730.html
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev