[llvm-dev] RFC phantom memory intrinsic
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 26 11:11:45 PDT 2017
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...
On 09/12/2017 12:54 AM, Dinar Temirbulatov via llvm-dev wrote:
> 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
> %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:
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev