[PATCH] Fix instcombine's folding of select into phi nodes for ConstantExpr

Duncan P. N. Exon Smith dexonsmith at apple.com
Fri Dec 6 13:23:42 PST 2013


On Dec 6, 2013, at 12:16 PM, Manman Ren <manman.ren at gmail.com> wrote:

> Just curious, do you know why the ConstantExpr in question stopped being constant-folded?

The ConstantExpr stopped being folded in r173995 [1]:

> Fix ConstantFold's folding of icmp instructions to recognize that, for example, a one-past-the-end pointer from one global variable may be equal to the base pointer of another global variable.
> 
> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173995 91177308-0d34-0410-b5e6-96231b3b80d8

[1]: https://github.com/llvm-mirror/llvm/commit/d363ae52995059906d99f7588f47bf891e7db485

The rationale is that given:

    @A = global i64 0
    @B = global i64 0
    @C = i1 icmp eq (i64* getelementptr inbounds(i64* @A, i64 1), i64* @B)

@C *can* be 1 when @A gets placed right before @B (i.e., depending on memory layout).

However, I’m looking into two things:

1. All folding was disabled when comparing GEPs into globals, but we can certainly re-enable it when the GEP indices are all 0 (or even more often, depending on the object-size of @A).
2. Is r173995 even necessary?  Isn’t it undefined whether @A and @B end up next to each other in memory?  Can’t the compiler optimize based on the assumption that they’re not adjacent?



More information about the llvm-commits mailing list