[llvm] [DAG] Add freeze(assertext(x)) -> assertext(x) folds (PR #94491)

Björn Pettersson via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 6 01:54:46 PDT 2024


bjope wrote:

> Actually, thinking about it a bit more, special-casing poison inputs simply doesn't work. We lower poison-producing operations to non-poison-producing operations, so you can't actually prove whether an operation originally produced poison.

Yes. That is a problem. And the idea with classifying it as immediate UB when violating the assert would be that such a lowering would be illegal (when the value is used by an "assertext").

> 
> Maybe we just want to transform `freeze(assertzext(x)) -> freeze(x)`?

I've ended up looking at this since I'm being blocked from pushing the miscompile bugfix in https://github.com/llvm/llvm-project/pull/84924 due to `freeze(assertzext(x)) ` resulting in lit test regressions (although I do not know if it result in any major real world regressions).
The goal here is therefore to keep the property of assertzext even if the result of the assert should be frozen. This to avoid blocking optimizations that could trigger given by the asserted condition.
Neither freeze nor assertzext actually modifies the register, so I don't really see how to freeze the value within a specific value range without adding any real operations. But if we can't eliminate the freeze here (or push it through the assertext), then I guess we should avoid pushing the freeze all the way to the assert in the first place, at least not in situations when it blocks other simplifications.

Anyway, I just want to fix the miscompile issues. And now I've been stuck in the posion/freeze jungle for a couple of months (sometimes just feeling that I get more and more confused the more I look at it).

https://github.com/llvm/llvm-project/pull/94491


More information about the llvm-commits mailing list