[PATCH] D59065: Add ptrmask intrinsic

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

In D59065#1501553 <https://reviews.llvm.org/D59065#1501553>, @jdoerfert wrote:

> In D59065#1501459 <https://reviews.llvm.org/D59065#1501459>, @fhahn wrote:
>
> > > - What happened to the poison result sentence. I think we need that to ensure the "based on the same ..." part. Otherwise, we can butcher the pointer with the mask and end up with a "valid pointer" into a different object. I might be wrong here, just want to make sure we have thought of it.
> >
> > My understanding from Hal's comments was that the behavior should be clear from the pre-existing semantics, but I might have missed something?
>
>
> I don't see why but I might be wrong (@hfinkel). What I thought is detailed below.
>
> > The case where we fail to clear bits that must be zero should be clearly handled by the existing semantics.
>
> Sure.
>
> > The case where we might clear meaningful bits
>
> I'm not sure about this. At least I think this is not what you intended to do initially but maybe this is OK for you.


Yes, the current definition is more permissive than the original one.

> With this definition, I don't see why clearing lower bits would result in poison as long as the result points into the
>  same object. Even if not, the current definition doesn't really state what would happen if the resulting pointer would point into any valid object.

It wouldn't be poison, unless ptrmask yields an inaccessible pointer through the masking operation.

I might be missing your point, but for the case ptrmask returning a pointer that "would point to any valid object", then the underlying object of the input pointer must be that object, as per definition, right? Transformations (and frontends) have to ensure no inconsistencies are introduced. Maybe that's worth calling out?


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

https://reviews.llvm.org/D59065