Reping :)

Took another shot at the wording. This should be a bit more explicit about what we're assuming, and what transforms are allowed.

LGTM

What I would like to do as follow up is to turn FunctionAttrs to use dominators info.

ping

In D51431#1262979, @efriedma wrote:

You're making the lattice really confusing. Essentially, there are now two different merging rules: one is used if the caller calls mergeInValue, and a different one is used if the caller calls markNotConstant etc. So it's not obvious what the lattice actually represents.

---

And actually, thinking about it a bit more, there's a more fundamental problem with proving a value is non-null. Given that a value is possibly-undef, it could be null even for code dominated by a null-check. So the entire proposed transform is unsound unless you freeze the pointer.

The patch looks fine but since I don't know much about opencl I'll leave the LGTM to someone that actually knows this code.

apply edits of @vlad.tsyrklevich

In D53336#1266890, @vlad.tsyrklevich wrote:

I sent you my StackSafetyAnalysis.rst edits over e-mail because the s/// format got tricky.

LGTM

And I expect this will be noisy in tests

The patch shows the current idea so we can consult the design first, and then do boring marking work.

LGTM

Brian checked the extra argument for dpp mov should be the first one. so mov_dpp(x,...) --> update_dpp(undef, x, ...). I will fix that when committing.

I think we still need the clang patch to preemptively strip nonnull annotations from C library functions before we turn on EnableNonnullArgPropagation by default, to be safe. But yes, the right approach is to add the correct nonnull attributes, then enable nonnull propagation.

LGTM. Is this only actually a problem with the UB because we don't bother trying to set m0 to the allocated size?

LGTM

Superseding with a version that seems to work