<div><div dir="auto">Indeed. But the problem here is that Dinar is trying to keep information after a load/store is removed by instcombine</div><div dir="auto"><br></div><div dir="auto">For example:</div><div dir="auto"><br></div><div dir="auto">v4sf v = {p[0], p[1], p[2], p[3]};</div><div dir="auto">v4sf v2 = shuffle(v, 0, 0, 2, 2);</div><div dir="auto"><br></div><div dir="auto">Some pass comes in and removes the p[3] and p[1].</div><div dir="auto"><br></div><div dir="auto">Now you have smaller code, but lost the ability to use a vector load for all those values + shuffle. The code got scalarized because we lost the information that p[3] is valid.</div><div dir="auto"><br></div><div dir="auto">The attribute on a value/load/something might not be ideal (especially since we'd be changing other loads (ones we didn't remove)). But I think Dinar wanted to start a conversation about how we can keep this information around even after we delete some loads.</div><div dir="auto"><br></div><div dir="auto">Thank you,</div><div dir="auto"><br></div><div dir="auto"> Filipe</div><br><div class="gmail_quote"><div>On Wed, 19 Jul 2017 at 12:53, Nuno Lopes via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When a pointer is passed to load/store, it's already implicit that it is<br>
dereferenceable for the size of the access (otherwise it would be undefined<br>
behavior).<br>
Isn't that information sufficient for your use case? (sorry, didn't read<br>
the whole thread carefully).<br>
<br>
Nuno<br>
<br>
-----Original Message-----<br>
From: Dinar Temirbulatov via llvm-dev<br>
Sent: Tuesday, July 18, 2017 7:36 PM<br>
Subject: [llvm-dev] [RFC] dereferenceable metadata<br>
<br>
Hi,<br>
While working on PR21780, I used "dereferenceable_or_null" metadata<br>
and I realized now that it is not correct for my solution to use this<br>
metadata type since it might point to an address that it is not<br>
dereferenceable but null. I think that we need another new metadata<br>
type, something like "dereferenceable" with that we could annotate<br>
any load (not just pointer type like with dereferenceable_or_null).<br>
For example, we could annotate this load : "%ld0 = load double,<br>
double* %ptr, align 8" with dereferenceable<2> and that means that for<br>
%ptr address memory with length 16-bytes is known to be<br>
accessible(dereferenceable). Originally in PR21780, InstCombine pass<br>
removed some loads as dead(in a Scalar IR form) and later that<br>
prevented us to vectorize the operation, but before removing such<br>
loads we could annotate the remaining loads in the series with<br>
"dereferenceable" and later restore IR in a way that is suitable for<br>
vectorization(see <a href="https://reviews.llvm.org/D35139" rel="noreferrer" target="_blank">https://reviews.llvm.org/D35139</a> ). Also, please note<br>
that’s the information that is lost when InstCombine kills the last<br>
load in the series and there is no way to restore this information<br>
later in following passes.<br>
Thanks, Dinar.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>