[LLVMdev] The nsw story

[David A. Greene]

Dan Gohman <gohman at apple.com> writes:

> For example, suppose we want to convert the && to &, and the ?: to a
> select, in this code:
>
> if (a && (b ? (c + d) : e)) {
>
> because we have a CPU architecture with poor branch prediction, or
> because we want more ILP, or because of some other reason. Here's what the
> LLVM IR for that might look like:
>
>    %t0 = add nsw i32 %c, %d
>    %t1 = select i1 %b, i32 %t0, i32 %e
>    %t2 = icmp ne i32 %t1, 0
>    %t3 = and i1 %a, %t2
>    br i1 %t3, ...
>
> The extra branching is gone, yay. But now we've put an add nsw out there
> to be executed unconditionally. If we make the select an observation
> point, we'd have introduced undefined behavior on a path that didn't
> previously have it.

Unless the undefined behavior only triggered if the select actually
produced a poisoned result.  Then it should have the same behavior as
the branch, no?

> A foodtaster instruction doesn't really solve this problem, because
> we'd have to put it between the add and the select, and it would be
> just as problematic.

Or you put it immediately after the select.

> One could argue that aggressive speculation is a low-level optimization
> better suited to CodeGen than the optimizer, as LLVM divides them, and
> that perhaps the cost for providing this level of flexibility in the
> optimizer is too high, but that's a different argument.

No, I think we want the flexibility.  But I believe there are sane ways
to do this.

                             -Dave