LGTM
(there's only a typo in the comment "singned")

The patch looks good to me. Actually I had reported this bug a while back as well: https://bugs.llvm.org/show_bug.cgi?id=42699
I agree we can't have objects larger than half of the address space.

Clarify semantics for pointers.

In D29121#1696095, @lebedev.ri wrote:

@nlopes anything holding this patch? do you intend to land them all at once?
@aqjune I suppose D29011 should be the next one up for review..

Made it explicit re one vs multiple calls to freeze.

Updated with an example with vectors and add more references to freeze section.

Reflect comments & clarify immediate UB when branching on poison.

In D64215#1577194, @reames wrote:

In D64215#1572285, @nlopes wrote:

In D64215#1572070, @reames wrote:

In D64215#1571424, @nlopes wrote:

Just a shameless plug :)
We've been half secretly working on Alive2 (https://github.com/AliveToolkit/alive2), which includes a plugin for opt that can check if an optimization is correct or not. Alive2 also has a standalone tool that accepts 2 IR files instead.

I'd tried playing with Alive2 a while ago, and had trouble getting it to work. Could you maybe update the readme (or other docs) with some instructions on how to use the standalone tool you mentioned? I'd very much like to play with this.

I've just added a short description to the README file: https://github.com/AliveToolkit/alive2#running-standalone-translation-validation-tool-alive-tv
It's fairly simple: it just takes 2 LLVM IR files. Let me know if you have questions or if you find bugs :)

This tool implements the semantics of poison for many LLVM instructions, and already has some support for memory (which is quite hard to handle).
Of course, what this patch does is not the same. This patch is more executable, while Alive2 requires Z3 to reason about the semantics (though it can also execute code very slowly).

I'd love to explore options for sharing the semantics here. What form does Alive2 express them in?

That's still a unsolved research problem. No one really knows how to share semantics still.
The semantics in Alive2 are written in C++, using an embedded expression language. While it is potentially possible to reuse that somewhere else, it isn't trivial. See e.g. the ir/instr.cpp file.

One thought on sharing.

From what I can tell from a quick look at the code you mentioned, it looks like you're parsing IR into an expression language, then rewriting the expressions to propagate poison - in a fairly similar manner to this code, but over your expression language - and then translating that expression language to SMT. Is that a good high level summary?

In D64215#1574483, @reames wrote:

In D64215#1572285, @nlopes wrote:

In D64215#1572070, @reames wrote:

In D64215#1571424, @nlopes wrote:

Just a shameless plug :)
We've been half secretly working on Alive2 (https://github.com/AliveToolkit/alive2), which includes a plugin for opt that can check if an optimization is correct or not. Alive2 also has a standalone tool that accepts 2 IR files instead.

I'd tried playing with Alive2 a while ago, and had trouble getting it to work. Could you maybe update the readme (or other docs) with some instructions on how to use the standalone tool you mentioned? I'd very much like to play with this.

I've just added a short description to the README file: https://github.com/AliveToolkit/alive2#running-standalone-translation-validation-tool-alive-tv
It's fairly simple: it just takes 2 LLVM IR files. Let me know if you have questions or if you find bugs :)

I finally got it working, required a couple changes to the CMakeFiles and an LD_PRELOAD (for unclear reasons). However, it doesn't look like the scope of the alive-tv tool is anywhere near wide enough for my purposes.

Correct me if I'm wrong, but it looks like it can't handle loops at all right? And use of any memory seams to trigger timeouts? (Even for trivially identical IR?) Just making sure there's no error between keyboard and chair. :)

In D64215#1572070, @reames wrote:

In D64215#1571424, @nlopes wrote:

Just a shameless plug :)
We've been half secretly working on Alive2 (https://github.com/AliveToolkit/alive2), which includes a plugin for opt that can check if an optimization is correct or not. Alive2 also has a standalone tool that accepts 2 IR files instead.

I'd tried playing with Alive2 a while ago, and had trouble getting it to work. Could you maybe update the readme (or other docs) with some instructions on how to use the standalone tool you mentioned? I'd very much like to play with this.

Just a shameless plug :)
We've been half secretly working on Alive2 (https://github.com/AliveToolkit/alive2), which includes a plugin for opt that can check if an optimization is correct or not. Alive2 also has a standalone tool that accepts 2 IR files instead.
This tool implements the semantics of poison for many LLVM instructions, and already has some support for memory (which is quite hard to handle).
Of course, what this patch does is not the same. This patch is more executable, while Alive2 requires Z3 to reason about the semantics (though it can also execute code very slowly).

LGTM, thank you!

Sounds great! Just 1 comment inline.

LGTM.
Minor: you have a typo in the comment: "return return"

I believe the contains function I wrote is correct. It says that an integer n belongs to interval I iff n >= lower(I) and n < upper(I) is there's no wrapping.
BTW, function isWrappedSet() just changed recently, so that needs tweaking in the Z3 model I sent (https://github.com/llvm-mirror/llvm/blob/master/lib/IR/ConstantRange.cpp#L347)

This patch is not correct for this input:
lhs = FullSet
rhs = [0, 1)

In D56155#1342651, @nikic wrote:

Based on the current documentation of poison values, selecting over poison is still poison by the first rule. I'm assuming that this is an inaccuracy in the documentation and selects are treated the same ways as phis? Otherwise the cited clang code would be affected.

As a justification why it doesn't matter whether it's undef or poison, clang emits__builtin_ffs as:
ffs(x) -> x ? cttz(x) + 1 : 0

In D54237#1291405, @nikic wrote:

Regarding

// X + undef -> undef
// undef + X -> undef
if (match(Op1, m_Undef()) || match(Op0, m_Undef()))
  return UndefValue::get(ReturnType);

I was initially planning to include these simplifications, but ultimately was not certain regarding their legality. In particular, if we have uadd.sat(MaxValue, Y), then the result is fully determined to be MaxValue, regardless of the value of Y. If we have something like sadd.sat(SignedMinValue, Y) then the result is known to be negative. In either case the intrinsic cannot have the full range of results of the result type, regardless of the value of Y. As such, I think folding operations on undef to undef would not be legal in this case.

It should be possible to fold uadd.sat(X, undef) to MaxValue. Not sure how useful that is though.

Sure, adding nsw/nuw brings in poison. I didn't study all the MI transformations going on, so I can't comment on whether this is a big burden or not, but without such a study introducing poison is dangerous.
SDAG already has nsw/nuw IIRC, though. But I don't think there was a thorough study of the implications at the time either.

In D49042#1155256, @sanjoy wrote:

Does this mean we can "construct" undef as:

x = alloca 0
y = alloca 0
undef = x == y  // Non-deterministically 0 or 1

? If so, this is a problem since it means even if we spec un-initialized memory as poison we still have undef in the IR (with all the problems it brings).

BTW, I couldn't figure if this case is possible, but mentioning it just in case: it's also not legal to introduce 'sdiv undef, ..', since 'sdiv INT_MIN, -1' is UB. Same for srem. So we need to be careful when folding the shuffle on LHS as well.

In D48893#1152112, @spatel wrote:

In D48893#1151840, @nlopes wrote:

shl %x, undef is poison; we don't want more undefs :)
So this transformation for shifts is not correct. The way to make it correct would be to introduce a poison value and use it in the shuffle instructions instead of undef. I suggest we finally go ahead and do that.

1. Does the 'undef' in the shuffle mask represent something different than the 'undef' in the shift amount?

shl %x, undef is poison; we don't want more undefs :)
So this transformation for shifts is not correct. The way to make it correct would be to introduce a poison value and use it in the shuffle instructions instead of undef. I suggest we finally go ahead and do that.

LGTM

Yes, although hopefully align(4) would have also been specified on the function argument. As the reference must have been bound to a valid object, from C++ semantics, we should know that it's properly aligned. Do we do that now?

I just got a scary ah-ah moment..
Take this code:

The C++ standard defines this as UB: http://eel.is/c++draft/conv.fpint#1
"A prvalue of a floating-point type can be converted to a prvalue of an integer type. The conversion truncates; that is, the fractional part is discarded.
The behavior is undefined if the truncated value cannot be represented in the destination type."

LGTM

Eli, thanks a lot for kicking off the discussion. I think this patch is a bit too big since there are a few things that are not trivial.
For example, I would rather not introduce more functions returning undef, but rather return poison instead. If there's no good motivation for undef, poison should be used by default from now on, since it's much easier to handle than undef.
This patch also introduces a lot of UB with metadata tags, which is a departure from how we handle things like nsw/nuw which make the instructions yield poison instead of UB. Why is it more important to preserve nsw when hoisting an add than preserving !nonnull when hoisting a load? I really don't know; hence I'm asking.
I think it would help to split this patch a bit.

The optimization looks good to me.

LGTM, but I would wait for another review due to the size of the change.

I like the direction in general. I've reviewed this patch and it LGTM (as well as the overall plan).
There are still a few corner cases we need to fix regarding the meaning of size -1, but I guess it's an orthogonal fix. Right now I don't know exactly what -1 size is: does it mean potentially access the whole object, or access the object from the current offset and potentially until the end?

Please don't remove non-functional changes from this patch. It contains dozens of indentation changes which are completely unrelated with the intended change and make the review more difficult. There are also debug printfs included that need to be removed :)
This document may be useful: http://llvm.org/docs/Contributing.html

Thanks @dberlin and @george.burgess.iv. I wasn't aware of this issue.

Given that the original motivation for these lifetime intrinsincs was for inlining, I don't see a reason to support multiple start/ends on the same pointer.
Or is there another new use case that I'm unaware of? Also, we don't have any transformation splitting (or even shrinking I think) these lifetimes.

oh, wow, so many bugs in DAG combiner handling undef.. Nice table btw!

In D41944#978753, @magabari wrote:

In D41944#978691, @nlopes wrote:

Before accepting this patch, we really need to see benchmark results. I'm not going to change clang to start emitting non-UB divs if the perf is going to be horrible. We need data.
Otherwise I don't see the need for this poison version of division. Could you elaborate if your plan is to expose this somehow to the application developer?

I'm sorry if this questions have been properly answered in the past. If so, could you please link them here?

In general the proposed feature allows compiler to start speculating div without worrying too much of div-by-zero etc. so for example you can do instruction hoisting or vectorizing predicated sdiv.
We are currently focused on vectorizing predicated div instruction and our implementation shows around 20-30% improvements on several tests of coremark-pro and denbench.

Before accepting this patch, we really need to see benchmark results. I'm not going to change clang to start emitting non-UB divs if the perf is going to be horrible. We need data.
Otherwise I don't see the need for this poison version of division. Could you elaborate if your plan is to expose this somehow to the application developer?

In D40670#954573, @yaxunl wrote:

In D40670#952389, @nlopes wrote:

In D40670#947019, @yaxunl wrote:

How about introduce nullptr value for each addr space in data layout? E.g., assume alloca addr space is 3 and nullptr value of addr space 3 is -1. alloca of addr space 3 could return 0, but never return -1.

Then this code

if (isa<AllocaInst>(V) && Q.DL.getAllocaAddrSpace() == 0)

can be changed as

if (isa<AllocaInst>(V) && Q.DL.getAllocaNullPointerValue() == 0)

This assumes that alloca never returns nullptr value.

Nuno, Sean, will this work for you?

Thanks.

Sorry for the delay.
What if a target doesn't have an invalid pointer? This is not uncommon in embedded ISAs.

I don't particularly like the idea of mixing null pointers (which we define as having the value zero ATM), alloca not being able to return a null pointer, and the possibility of changing the value of null pointers to a non-zero value.

How about adding a hook TargetTransformInfo::isAllocaPtrValueNonZero which returns true if alloca inst value is always non-zero.

The drawback is that some ValueTracking functions will depend on TargetTransformInfo. As a result, those passes using ValueTrackign will require TargetTransformInfo.

What do you think?

Thanks.

In D40670#947019, @yaxunl wrote:

How about introduce nullptr value for each addr space in data layout? E.g., assume alloca addr space is 3 and nullptr value of addr space 3 is -1. alloca of addr space 3 could return 0, but never return -1.

Then this code

if (isa<AllocaInst>(V) && Q.DL.getAllocaAddrSpace() == 0)

can be changed as

if (isa<AllocaInst>(V) && Q.DL.getAllocaNullPointerValue() == 0)

This assumes that alloca never returns nullptr value.

Nuno, Sean, will this work for you?

Thanks.

This change is incorrect. null can be a valid pointer in a non-0 address space, and alloca may return it.
If your target's address space guarantees that alloca doesn't return null, then we can probably make this target-dependent. But we cannot simply make it unconditional; that's not correct.

In D38569#933068, @asbirlea wrote:

An immediate usecase I have in LICM, is in very large testcases where I want to rely on MemorySSA's threshhold for optimizing MemUses.
I need to use getDefiningAccess() on a Use and query if the result given is May_Alias or Must_Alias. If the Use is not optimized, the result will always be MayAlias. If optimized, it may be May or Must.
Alias info is needed to avoid an additional AA.alias call when creating mssa alias sets for promotion.

It can certainly be used for more complex optimizations, aliasing between MemDefs is the most interesting to me. Since in MemorySSA all stores clobber all stores (until optimized), must alias info could be used to shortcut def alias chains. AFAIK this is done for MemUses, I don't think it's done for MemDefs.

This patch LGTM, except for the changes in tryFactorization(). It seems there's some code missing.

The concept looks interesting to me. I'll let the experts review the patch, though (I just skimmed over it).
Out of curiosity, what are the clients you envision could use this functionality?
I can imagine that we can do store forwarding with a mustalias MemUse if stored size >= load size. Also, a mustalias MemDef can kill the previous MemDef if it has no other uses (2 stores to same location).
Are there any other uses cases? Can it be used to simplify more complex optimizations? Even better, are there missing blocks that would be needed to simplify these optimizations? (tricky question; just wondering if you have some thoughts on that).

Ok, mea culpa, I thought CreateBitOrPointerCast() would simply create a bitcast.
Then, what we have here is:

v = phi(ptr2int(p), ptr2int(q))
 =>
v = ptr2int(phi(p, q))

In D37832#875262, @davidxl wrote:

As I have mentioned, this patch itself does *not* fold any ptrtoint/inttoptr. It simply moves the intptr across the phi node. The folding you see with the test cases is done by existing optimizations, so I am not sure what the objection is about.

Ok, so after another scan through the patch and a discussion with Gil, I must say the transformation is not fully correct.

In D37832#873621, @nlopes wrote:

This transformation looks correct to me and goes in the right direction (remove unneeded int2ptr/ptr2int, since they block many optimizations). The patch can be made a bit more general later.
Before the patch goes in, please add a few negative tests; you only have positive ones. Thanks!

This transformation looks correct to me and goes in the right direction (remove unneeded int2ptr/ptr2int, since they block many optimizations). The patch can be made a bit more general later.
Before the patch goes in, please add a few negative tests; you only have positive ones. Thanks!

LGTM, thanks.
You're right: the Boolean connector for the second transformation was flipped. All good now :)

I was trying to prove this in Alive, but the proof doesn't go through.
Some corner cases are not correct: http://rise4fun.com/Alive/iVs
For example: 'INT_MIN / something' would be replaced with 0, but shouldn't.