Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Check Widening in LLVM

playingwithpointers.com

Post reply on HN
Print view View original

1–10 of 13 posts

Re: Check Widening in LLVM

#2

Post by TempleOSV409 »

Good call. I checked river sand-bar width in the old code. It turns-out that it offset by random x and y. Currently, I have just x offset. The old code with y sandbar offset caused bigger bars.

It's good, now. Thanks for taking interest. It's true I was negligent not investigating.

Re: Check Widening in LLVM

#6

Post by cfallin »

tedunangst wrote: post #4

> Now if arr.length is 1 then we’ll deoptimize to the interpreter with false as the value of 0 u How so? Why does the test change?

The optimizer recognizes that the variable `condition` and the condition with the guard's if-statement are the same (edit: inverses actually), so within the if-statement's body, it can assume that `condition` is false. But when other guard cases are merged in, that's no longer the case.

In other words, the general optimization is to convert

    bool A = condition(); 
    if (!A) { f(A); }
to:

    bool A = condition();
    if (!A) { f(false); }
i.e., that we can assume an if-condition is true within the body of that if-statement. The problem is that the check-widening reuses the body of the if-statement: the code

    bool A = condition();
    if (!A) { f(A); }
    bool B = condition();
    if (!B) { f(A); }
is converted by check-widening to the first snippet above, which then becomes the second. Sanjoy's observation is that guard-widening is almost correct (we still want to pursue this route) because `f` (the deoptimization escape) is really what we want to call in both cases, but we just need to get the value of `A` right by somehow letting the optimizer know that we're reusing the if-body and that it can't assume anything about the condition that got us there.

Also, this is really really clever and I enjoyed the post, OP!

Re: Check Widening in LLVM

#7

Post by tedunangst »

cfallin wrote: post #6
tedunangst wrote: post #4

> Now if arr.length is 1 then we’ll deoptimize to the interpreter with false as the value of 0 u How so? Why does the test change?

The optimizer recognizes that the variable `condition` and the condition with the guard's if-statement are the same (edit: inverses actually), so within the if-statement's body, it can assume that `condition` is false. But when other guard cases are merged in, that's no longer the case. In other words, the general optimization is to convert bool A = condition(); if (!A) { f(A); } to: bool A = condition(); if (!A) { f…

Thanks. I think I understand, but would have liked to see the lowered version with the reused/rewritten condition.

Re: Check Widening in LLVM

#8

Post by pcwalton »

drfuchs wrote: post #5

Why "discard the current runtime frame, and resume execution in the interpreter" rather than jump into a compiled but unoptimized version of the function?

You could do the latter too, and that's what V8 does for example (at least until they roll out the interpreter).

Re: Check Widening in LLVM

#10

Post by sanjoy_das »

tedunangst wrote: post #7
cfallin wrote: post #6

Earlier quoted context omitted.

The optimizer recognizes that the variable `condition` and the condition with the guard's if-statement are the same (edit: inverses actually), so within the if-statement's body, it can assume that `condition` is false. But when other guard cases are merged in, that's no longer the case. In other words, the general optimization is to convert bool A = condition(); if (!A) { f(A); } to: bool A = condition(); if (!A) { f…

Thanks. I think I understand, but would have liked to see the lowered version with the reused/rewritten condition.

Is this what you're looking for: http://www.playingwithpointers.com/check-widening-in-llvm.ht... ?
Post reply on HN