[llvm-dev] [RFC] Increase the scope of Value::getPointerXXX methods

Finkel, Hal J. via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 22 22:58:32 PDT 2019

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.


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<mailto:llvm-dev at lists.llvm.org>

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190823/084f44a0/attachment.html>

More information about the llvm-dev mailing list