[llvm-dev] [RFC] Increase the scope of Value::getPointerXXX methods
Doerfert, Johannes via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 22 23:18:11 PDT 2019
On 08/23, Finkel, Hal J. wrote:
> On 8/22/19 12:32 PM, Doerfert, Johannes via llvm-dev wrote:
> Right now, we have Value::getPointerDereferenceableBytes() and
> Value::getPointerAlignment() that allow to query these properties for a
> value. However, neither does any "reasoning" that would require looking
> at other values, e.g., they do pure local lookups. To do actual
> reasoning we have the "isDereferenceableAndAlignedPointer()"-family of
> functions in Loads.h. Additionally, various places duplicate parts of
> the necessary logic to deal with alignment and dereferenceability
> because the result of the "isDereferenceableAndAlignedPointer" is often
> not sufficient, e.g., we want the number and not test a specific number.
> Now I see two ways that would improve the situation here, I mean to
> actually allow outside user to get dereferenceable bytes and alignment
> information without copying the logic, we could:
> (1) Make the Value methods "smarter", or
> (2) expose more information through helper functions, e.g., a "smart"
> getDereferenceableBytes and getAlignment that live outside of the
> Value class.
> We seem to have developed a trend toward putting more of these kinds of
> stateless analysis functions into the core IR library instead of having them in
> Analysis. I'm not sure that this is desirable. My inclination is to say that we
> should have the functions in the Analysis library - and then make them as smart
> as we'd like without worrying about potential layering restrictions.
https://reviews.llvm.org/D66618 shows how a solution with a single
function (per property) in the analysis library could look like. It is
not 100% clean and I can first move the code before I add the GEP
functionality but the general idea should become clear. The impact on
the test, assuming I didn't overlook an error, seems also be to
consistently positive (with the execption of the one loop fusion test).
> Option (1):
> - Less confusion which methods to use, especially if we add helper
> function to "compute" the information, e.g., getDereferenceableBytes
> outside of Value. We would have one set to expose raw information,
> the Value::getXXXX methods, and one set to have them put in context,
> the isYYYY helpers.
> - The Value::getXXX methods are not pure lookups for that particular
> value anymore but they also include logic.
> Option (2):
> Benefits and drawbacks are basically the opposite of Option (1).
> I want to clear this because I have a patch to improve the GEP handling
> wrt. dereferenceable bytes and alignment. I need improvement in parts
> because isDereferenceableAndAlignedPointer is "smart" when it comes to
> dereferenceability of GEPs but not when it is about alignment. Also, the
> handling we have is not optimal and probably replicated a few times.
> One last caveat: I'd also like to reuse whatever we come up with in the
> Attributor framework to not duplicate the logic there. That means I want
> a way to add "optimistic/assumed" information into a lookup. I guess the
> cleanest is an optional lookup function that can be provided. We can add
> it to both Option (1) and (2) but I wanted to mention this already.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
Argonne National Laboratory
Lemont, IL 60439, USA
jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the llvm-dev