search for: widenable_condition

...r load/store in the function, but doesn't allow CSE to eliminate it. It is not actually super-cool, because there is no way that we can safely hoist it out of loop (and sometimes we want to, for example to make unswitching). So this part is a one I am still thinking about. As an alternative to widenable_condition() call, we are considering loads from special dedicated global fields. The bad thing about them is that if a loop gets peeled, then a widenable condition in the loop can be optimized away basing on fact that this field was true on the 1st iteration. Thanks, Max -----Original Message----- From: Sa...

...is even worse). So basically, the only thing we need to distinguish the guard is a special type of undef value which will not be optimized away by other transforms (at least not before we are done with widening-based transforms). To solve that, we can introduce a special intrinsic that is called widenable_condition(). And we can just use it instead of the undef here like this: %wc = call i1 widenable_condition() %guard_cond = and i1 %cond, %wc br i1 %guard_cond, label %guarded, label %deopt guarded: <do some useful stuff> deopt: <deoptimize and leave the compiled...