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

[Doerfert, Johannes via llvm-dev]

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.

Option (1):
Benefit:
 - 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.
Drawback:
 - 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.

Cheers,
  Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190822/b94914a0/attachment.sig>