[PATCH] D89456: [SCEV] Introduce SCEVPtrToIntExpr (PR46786)

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Apr 18 07:37:17 PDT 2021


lebedev.ri added a comment.

In D89456#2697285 <https://reviews.llvm.org/D89456#2697285>, @nikic wrote:

> In D89456#2697284 <https://reviews.llvm.org/D89456#2697284>, @lebedev.ri wrote:
>
>> In D89456#2697266 <https://reviews.llvm.org/D89456#2697266>, @nikic wrote:
>>
>>> SCEVUnknown is implemented as a value handle that nulls out the SCEV expression on deletion, and whenever a SCEV expression for a Value is looked up, we check whether there are any nullptr SCEVUnknowns and discard them in that case.
>>>
>>> As SCEVPtrToInt is really similar to SCEVUnknown, I've been wondering why we need this handling for SCEVUnknown but not for SCEVPtrToInt.
>>>
>>> (I don't have any particular reason for this question, just confused while reading the code...)
>>
>> `SCEVPtrToInt` isn't really similar to `SCEVUnknown`, because former is a "proper" SCEV expression,
>> with a SCEV expression parent, while latter is a "root" expression, with LLVM IR `Value*` as a parent.
>> So i wouldn't see why it would need the same handling as `SCEVUnknown`.
>> Or to reword, shouldn't then every single SCEV expression have that same handling as `SCEVUnknown`?
>
> Oh, of course! I got really confused here. For some reason I thought that SCEVPtrToInt directly referenced an IR value. I have no idea where I got that impression in the first place, it doesn't make sense.

It does make sense, and that would be a totally valid model for `SCEVPtrToInt`, but i specifically choose *not* to use it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89456/new/

https://reviews.llvm.org/D89456



More information about the llvm-commits mailing list