There's also a todo in a comment in nilcheckelim for this. The right fix is probably a one liner in the front end, though, marking the return value of the runtime call as Bounded.

Yes. We have to be a bit careful, though. I think there is some confusion (in my head, at least) if Bounded marks a pointer that is non-nil, or a dereference which will not fault. The former could be on any op that generates a pointer, the latter would only be on OIND or ODOTPTR (any others?). The tricky part is we need to pick one or the other, a mix won't work.
Bounded for bounds checks uses the latter meaning, as there is no way for it to mean the former (it would have to be on a pair of slice+index somehow). So Bounded for pointer nilness should probably work the same way.
But that means just marking the return value of newobject isn't the right thing. You must mark all the OIND that use newobject. That isn't as easy.
Or we add a new mark to nodes for the non-nil attribute.

You're right. I think we should add a new non-nil attribute to nodes. We might also want to add a unique/bespoke attribute as well, which would be a cleaner and cheaper way to accomplish CL 21937. We'll probably need to give Node a bitmap and get rid of some of its bools in the process, but that's desirable anyway.

I have a CL which already does this for map return values in an ad-hoc fashion: https://go-review.googlesource.com/c/22291/
Let me know if someone picks this up and we can adjust that CL appropriately.

CL https://golang.org/cl/22291 mentions this issue.

We can do the Node bitmask and Bespoke thing later.

Actually, this isn't fixed. There's nothing propagating the NonNil flag I added. So when you do:

p := new(T)
x := *p

It compiles to OAS(p, OCALL(...)). The OCALL has the NonNil flag, but it never gets copied to p, so the indirection *p still has a nil check.
It's tricky to copy it to p during walk, because p may be redefined later.
Maybe SSA could pick up this flag and propagate it. Have to think about it.

Propagating this is exactly the sort of thing that nilcheckelim does. Maybe instead of eliminating the nilcheck at ssa construction time, we add a hint that the nilcheck can be eliminated, and pick up that hint at the beginning of nilcheckelim? It's slightly wasteful, but avoids a bunch of new mechanism.

CL https://golang.org/cl/27930 mentions this issue.

@cherrymui , why doesn't your CL 27930 fix this?

I think it does. I wasn't sure whether it covers all the cases, letting you and Josh to decide.

@randall77 The rules are commented out in the new nilcheck mechanism. I couldn't find a problem if I re-enable them. Is there a reason?

Ah, yes, that was me. If re-enabling doesn't cause a problem, go ahead and do that.