This is an archive of the discontinued LLVM Phabricator instance.

Make `@llvm.objectsize` more conservative with null pointers.
ClosedPublic

Authored by george.burgess.iv on Jan 9 2017, 3:17 PM.

Details

Summary

In pursuit of fixing https://llvm.org/bugs/show_bug.cgi?id=23277, we'd like @llvm.objectsize to treat null pointers as opaque/unknown pointers, rather than treating them as pointers to 0 bytes of memory. This patch adds an argument to @llvm.objectsize that lets us control how @llvm.objectsize treats null.

As Sanjoy noted in http://lists.llvm.org/pipermail/llvm-dev/2017-January/108623.html, we can also make a backwards-incompatible change that just makes @llvm.objectsize adopt this null-is-unknown-size behavior in all cases. I dunno what the better option is here, but we could easily do that by throwing basically half of this patch out (all except for the changes to MemoryBuiltins).

If we want the absolutely-minimal patch, we could cut the changes to MemoryBuiltins.cpp down to a few lines (just returning unknown() in ObjectSizeOffsetVisitor::visitConstantPointerNull). Doing so would cause us to delay lowering the calls to @llvm.objectsize as much as possible, which may inhibit some optimizations.

There's a handful of tests with @llvm.objectsize in them that this patch doesn't update, since they don't CHECK for objectsize with a specific set of arguments. If we want, I'm happy to update them to use the three-arg version, as well.

I wasn't entirely sure who to poke with this, since I can't find a code owner for intrinsics. :)

Diff Detail

Repository
rL LLVM

Event Timeline

george.burgess.iv retitled this revision from to Make `@llvm.objectsize` more conservative with null pointers..
george.burgess.iv updated this object.
george.burgess.iv added a subscriber: llvm-commits.
ahatanak added inline comments.
lib/Analysis/MemoryBuiltins.cpp
439 ↗(On Diff #83710)

Is there a possibility that, when NullIsUnknownSize=true and MustSucceed=false, returning a ConstantInt instead of a nullptr can cause InstCombine to prematurely optimize away objectsize?

I'm thinking about a case where the first operand of objectsize is "select %cmp, null, %someptr". If %cmp turns out to be false later and the size of the object "%someptr" points to is known, objectsize can be replaced with the exact size of the object.

george.burgess.iv marked an inline comment as done.

Addressed feedback

lib/Analysis/MemoryBuiltins.cpp
439 ↗(On Diff #83710)

Good point. I rewrote this to just return unknown, then. :)

echristo edited edge metadata.Feb 21 2017, 11:36 AM

One inline request, otherwise I think this is ok. Not sure if we want to use an i2/i8 rather than a pair of i1, but either way.

-eric

include/llvm/Analysis/MemoryBuiltins.h
146 ↗(On Diff #84868)

As an enhancement I'd love to see this encapsulated into a preferences struct or something rather than two bools and an enum.

arsenm added inline comments.Feb 21 2017, 11:36 AM
lib/Analysis/MemoryBuiltins.cpp
602–603 ↗(On Diff #84868)

I think this will do the wrong thing with non-0 address spaces

test/Transforms/InstCombine/objsize.ll
268 ↗(On Diff #84868)

Should add some tests with another address space to make sure it isn't treating 0 as an invalid pointer

george.burgess.iv marked 3 inline comments as done.
george.burgess.iv removed a reviewer: tstellarAMD.
  • Swapped to using an options struct for getObjectSize configuration
  • Only use relaxed checks in addrspace 0

(also removed tstellarAMD as a reviewer, since their account was deactivated)

Thanks for the comments!

include/llvm/Analysis/MemoryBuiltins.h
146 ↗(On Diff #84868)

Done.

FWIW, most users only care about RoundToAlign, so I played with having a ObjectSizeOpts::withRoundToAlign(bool) method, but I think getObjectSize(..., ObjectSizeOpts{}.withRoundToAlign(RoundToAlign)) ends up being a bit uglier than just making an ObjectSizeOpts and setting RoundToAlign directly. Happy to do withRoundToAlign instead if you think that's better.

lib/Analysis/MemoryBuiltins.cpp
602–603 ↗(On Diff #84868)

Good point; fixed.

echristo accepted this revision.Mar 16 2017, 4:28 PM

This is OK with me.

This revision is now accepted and ready to land.Mar 16 2017, 4:28 PM
This revision was automatically updated to reflect the committed changes.

Thanks for the review and comments, everyone! :)