Shifts are only isSafeToSpeculativelyExecute if we know the amount we're shifting by is smaller than the bitwidth of the shifted value.
This fixes PR30708
Differential D25847
[ValueTracking] Don't assume we can speculate shifts mkuper on Oct 20 2016, 3:59 PM. Authored by
Details
Diff Detail Event TimelineComment Actions LGTM, modulo nit. This was a little bit painful.
Comment Actions "A shift is undefined if the second operand is equal or larger than the number of bits in the first operand." Yes... but that's not undefined behavior. LangRef just says "the result is undefined".
Comment Actions hmm, does this change the fact that we don't want to speculate in this case or you're commenting on the wording? Comment Actions This looks wrong -- shifts should always be safe to speculate. I wasn't following PR30708 closely, but can you describe why you think shift speculation is the root cause for PR30708? Comment Actions In LangRef "the result is undefined" essentially means "returns undef", like a load from uninitialized memory. There isn't any reason we can't speculate a shift, as long as the result isn't actually used for anything. I would guess that we're performing a transformation which assumes that "lshr i32 1, %n" returns either 1 or 0, which isn't correct for n >= 32. Comment Actions Because of this comment on PR30708:
But, as Eli pointed out (thanks!), this isn't true. Comment Actions Oh, sorry, this is entirely my fault. I misread result undefined == undefined behaviour, that's where the confusion started. Sorry again! Comment Actions Nah, I've read the same text (several times, for each type of shift) and didn't catch it either. :-) |
Nit: I think the LLVM spelling is FIXME