[LLVMdev] The nsw story

[Andrew Trick]

On Dec 5, 2011, at 7:42 PM, Dan Gohman wrote:
> 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.
> 
> 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.
> 
> The current definition of nsw is an attempt to avoid arbitrary
> limitations and keep the system as flexible as possible.
> 
> 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.

The optimizations we're talking about are forms of safe
speculation. Doing that at IR level is fine.

Hardware support for NaT bits + check instructions have been popping
up on this message thread. Hardware speculation exists solely to
support unsafe speculation, in which certain operations need to be
reexecuted under certain conditions. It is not something we would ever
want to represent in IR. It isn't ammenable to CFG+SSA form.

Runtime checking for undefined behavior would be implemented as
overflow checks, etc. by the front end. I don't think it's related to
unsafe speculation. In other words, I don't see the purpose of a
"check/foodtaster" instruction.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111206/44f22850/attachment.html>