Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Definitely not. I've never seen that utility on Function, but whatever it's supposed to do, it completely ignores address spaces (our major source of defined nulls) while doing it.
A much simpler surgical fix would be to replace the use of getDereferenceableOrNullBytes with getDereferenceableBytes. This would eliminate the "or null concern" from the merge logic.
Johannes, I didn't take time to fully understand your concern, but if it's broader than the above, please revert the original patch and handle in normal review.
The utility function can take a address space and it is used in other places too. To give it the address spaces of the argument pointers would be an option, but ...
A much simpler surgical fix would be to replace the use of getDereferenceableOrNullBytes with getDereferenceableBytes. This would eliminate the "or null concern" from the merge logic.
Johannes, I didn't take time to fully understand your concern, but if it's broader than the above, please revert the original patch and handle in normal review.
... we can, as @reames noted, not change the _or_null part at all and only work on the deref(X) parts.
Hey, read back over this and realized my tone rather snappy here. Sorry about that, was annoyed at something else at the time I wrote this and it came through more than I realized. Sorry.
nullPointerIsDefined(F, AS) .. cool :)
Test is in extra file due to memcmp redefinition issue.
lib/Transforms/Utils/SimplifyLibCalls.cpp | ||
---|---|---|
206 ↗ | (On Diff #214938) | Now, one could just keep this annotation if NullPointerIsDefined(F, AS) was true. |
test/Transforms/InstCombine/mem-deref-bytes-addrspaces.ll | ||
6 ↗ | (On Diff #214938) | The point was, "null-pointer-is-valid"="true" should not be needed if the AS is set to (sth not known to have an invalid null). |
I like it. We don't loose information and it should be always correct. @reames, still concerned?
I have no problem with this patch (i.e. it can land if Johannes approves)
A conceptual point worth mentioning is that seems to essentially be inferring non-null for the intrinsics in question. We have a nonnull attribute on params and nonnull + deref_or_null should already be converted to deref. (If not, we should fix that.) It might be worth thinking about how to leverage the more generic code.
Next step (https://reviews.llvm.org/D53342) :) As noted in D53342 we need to be careful about adding nonnull.
LGTM.
A conceptual point worth mentioning is that seems to essentially be inferring non-null for the intrinsics in question. We have a nonnull attribute on params and nonnull + deref_or_null should already be converted to deref. (If not, we should fix that.) It might be worth thinking about how to leverage the more generic code.
The Attributor does this already but there are a few points where we need to improve it.
I think these patches should encode "known" information and the Attributor (run early) will combine whatever it can.