[llvm-bugs] [Bug 47592] New: SROA introduces inttoptr

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=47592

            Bug ID: 47592
           Summary: SROA introduces inttoptr
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: lebedev.ri at gmail.com
                CC: llvm-bugs at lists.llvm.org

This is reduced from real-world code.

https://godbolt.org/z/sxj4oz

struct S {
    int* data;
    int x, y, z;
};

S gen(S a) {
    S b;
    b.data = a.data;
    return b;
}

void escape(S);

int* entry(S a) {
    S b = gen(a);
    escape(b);
    return b.data;
}


or  


struct S {
    int* data;
    int x, y, z;
};

S gen(S a) {
    S b;
    b.data = a.data;
    return b;
}

int cond();
void sync0();
void sync1();
void escape0(int*);
void escape1(int*);

int* entry(S a) {
    S b = gen(a);
    if(cond()) {
        sync0();
        escape0(b.data);
    } else {
        sync1();
        escape1(b.data);
    }
    return b.data;
}


The story is as follows:
* Originally, there was no inttoptr's
* Then InstCombine`s `combineLoadToOperationType()` came, and changed `gen()`
to operate on integers
  As per
http://llvm.1065342.n5.nabble.com/RFC-Missing-canonicalization-in-LLVM-td76650.html#none,
  i suppose it's it whole purpose..
* Then, SROA sees accesses with non-identical types to that alloca slice - with
i64 and i32*,
  and decides to fall-back to largest integer-sized type, so it creates more
load/stores of i64,
  that then need to be inttoptr'd.
* We clearly fail to recover from that - no pass manages to cleanup those
inttoptr's.
  I have previously proposed https://reviews.llvm.org/D75505, but indeed,
  it has some compile-time impact:
 
https://llvm-compile-time-tracker.com/compare.php?from=871d03a6751e0f82e210c80a881ef357c5633a26&to=782be5b99377b62e998e4157ddede0fa296664b5&stat=instructions

I think we can agree that this situation isn't great.
inttoptr are (nowadays) treated as pretty opaque, so e.g. SCEV will fail to see
that both the %7 and %9 in second example are actually the same pointer..

I'm open to suggestions as to how we can resolve this.
IMHO, `combineLoadToOperationType()` shouldn't exist, but then the RFC didn't
come with an end-to-end test, so it isn't clear what larger problem it is
fixing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200921/4d03bb0b/attachment-0001.html>