[llvm-dev] [RFC] dereferenceable metadata
Nuno Lopes via llvm-dev
llvm-dev at lists.llvm.org
Wed Jul 19 12:53:25 PDT 2017
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
More information about the llvm-dev
mailing list