select i1 non-const, i1 true, i1 false has been optimized to
non-const. There is no reason that we can not optimize `select i1
ConstExpr, i1 true, i1 false` to ConstExpr.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/test/Transforms/InstSimplify/select.ll | ||
|---|---|---|
| 892 | Outdated comment. We should also have a test where the constant expression is poison-generating. | |
LGTM
| llvm/test/Transforms/InstSimplify/select.ll | ||
|---|---|---|
| 892 | Outdated comments are still there. | |
| llvm/test/Transforms/InstSimplify/select-inseltpoison.ll | ||
|---|---|---|
| 890 | I think | |
| llvm/test/Transforms/InstSimplify/select-inseltpoison.ll | ||
|---|---|---|
| 890 | Yes, strictly speaking this is also safe to fold, but would require analysis we don't currently do. To make it actually poison you'd need something like i32 ptrtoint (ptr getelementptr inbounds ([3 x ptr], ptr @a, i64 2) to i32). | |
I think
i32 ptrtoint (ptr getelementptr inbounds ([3 x ptr], ptr @a, i64 0, i64 1) to i32) doesn't produce poison.
index seems valid so maybe
i32 ptrtoint (ptr getelementptr inbounds ([3 x ptr], ptr @a, i64 1, i64 0) to i32) ?