[llvm-dev] [RFC] dereferenceable metadata

[Filipe Cabecinhas via llvm-dev]

Indeed. But the problem here is that Dinar is trying to keep information
after a load/store is removed by instcombine

For example:

v4sf v = {p[0], p[1], p[2], p[3]};
v4sf v2 = shuffle(v, 0, 0, 2, 2);

Some pass comes in and removes the p[3] and p[1].

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.

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.

Thank you,

 Filipe

On Wed, 19 Jul 2017 at 12:53, Nuno Lopes via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> When a pointer is passed to load/store, it's already implicit that it is
> dereferenceable for the size of the access (otherwise it would be undefined
> behavior).
> Isn't that information sufficient for your use case?  (sorry, didn't read
> the whole thread carefully).
>
> Nuno
>
> -----Original Message-----
> From: Dinar Temirbulatov via llvm-dev
> Sent: Tuesday, July 18, 2017 7:36 PM
> Subject: [llvm-dev] [RFC] dereferenceable metadata
>
> Hi,
> While working on PR21780, I used "dereferenceable_or_null" metadata
> and I realized now that it is not correct for my solution to use this
> metadata type since it might point to an address that it is not
> dereferenceable but null.  I think that we need another new metadata
> type, something  like  "dereferenceable" with that we could annotate
> any load (not just pointer type like with dereferenceable_or_null).
> For example, we could annotate this load : "%ld0 = load double,
> double* %ptr, align 8" with dereferenceable<2> and that means that for
> %ptr address memory with length 16-bytes  is known to be
> accessible(dereferenceable). Originally in PR21780, InstCombine pass
> removed some loads as dead(in a Scalar IR form) and later that
> prevented us to vectorize the operation, but before removing such
> loads we could annotate the remaining loads in the series with
> "dereferenceable" and later restore IR in a way that is suitable for
> vectorization(see https://reviews.llvm.org/D35139 ). Also, please note
> that’s the information that is lost when InstCombine kills the last
> load in the series and there is no way to restore this information
> later in following passes.
>                                          Thanks, Dinar.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/562874cc/attachment.html>