<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:11pt; color:black">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:11pt; color:black">Interesting approach but how do you handle more complex offsets, e.g., when the pointer is part of an aggregate? Only one offset does not seem enough to handle generic
cases.<br>
<br>
<span style="color:black">-----Original Message----- <br>
<b>From:</b> Dinar Temirbulatov via llvm-dev [llvm-dev@lists.llvm.org]<br>
<b>Received:</b> Dienstag, 12 Sep. 2017, 9:57<br>
<b>To:</b> llvm-dev@lists.llvm.org [llvm-dev@lists.llvm.org]<br>
<b>CC:</b> Filipe Cabecinhas [me@filcab.net]<br>
<b>Subject:</b> [llvm-dev] RFC phantom memory intrinsic<br>
<br>
</span></span></div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi,<br>
For PR21780 solution, I plan to add a new functionality to restore<br>
memory operations that was once deleted, in this particular case it is<br>
the load operations that were deleted by InstCombine, please note that<br>
once the load was removed there is no way to restore it back and that<br>
prevents us from vectorizing the shuffle operation. There are probably<br>
more similar issues where this approach could be applied.<br>
I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that,<br>
indicating that for particular pointer let's call it %ptr we observed<br>
maximum possible offset at which there was reference by its type in a<br>
function. After InstCombine deleted the load operation, it could be<br>
restored in SLPVectorizer and we could restore chains of GEPs, Loads<br>
and Inserts in case we encounter phatom_mem intrinsic.<br>
<br>
Here is two part review:<br>
<a href="https://reviews.llvm.org/D37579">https://reviews.llvm.org/D37579</a> - InstCombine part.<br>
<a href="https://reviews.llvm.org/D37648">https://reviews.llvm.org/D37648</a> - SLP part.<br>
<br>
Also, there might be different approaches in describing deleted memory<br>
operations, for example, for my case: phantom_load(llvm_anyptr_ty,<br>
llvm_i64_ty). First parameter describes pointer and second parameter<br>
offset from pointer this loaded was deleted, for example. This two<br>
operations:<br>
<br>
%arrayidx1 = getelementptr inbounds double, double* %ptr, i64 1<br>
%ld1 = load double, double* %arrayidx1<br>
<br>
could be represented in the IR with this one: "void phantom_load(%ptr,<br>
1)" after removal. But, the approach that is already implemented in<br>
both reviews looks better to me since we don't need to add intrinsic<br>
for every removed operation in the IR. Also, while constructing such<br>
form in the IR we have to be careful since some pointer operations<br>
might be in loops and as the result we might end up construction an<br>
incorrect IR. So, I just avoid to notice any pointer operation if it<br>
is belong to a loop, except those where the the whole chain of<br>
operations pointer origin, GEP, Load, Shuffle operation are in the<br>
same loop and in the same basic block.<br>
Thanks, Dinar.<br>
<br>
Here is the thread for this issue regarding using metadata:<br>
<a href="http://lists.llvm.org/pipermail/llvm-dev/2017-July/115730.html">http://lists.llvm.org/pipermail/llvm-dev/2017-July/115730.html</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
llvm-dev@lists.llvm.org<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</span></font>
</body>
</html>