[llvm-dev] Is it ok to allocate > half of address space?

[Björn Pettersson A via llvm-dev]

The example in https://bugs.llvm.org/show_bug.cgi?id=34344 is of course a reduced test case.
The problem was detected a runtime failures in one of our regression tests for large memcpy from one address space to another.

I'd welcome a correction for this (or at least that the compiler reports an error rather than producing incorrect code, assuming that it isn't undefined behavior to have such large allocations).

/Björn

> -----Original Message-----
> From: Nuno Lopes [mailto:nunoplopes at sapo.pt]
> Sent: den 8 november 2017 19:13
> To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>
> Cc: llvm-dev at lists.llvm.org; Mikael Holmén <mikael.holmen at ericsson.com>;
> efriedma at codeaurora.org
> Subject: Re: [llvm-dev] Is it ok to allocate > half of address space?
> 
> Many thanks for the pointer!  I missed that bug report since the title
> was about GVN.
> 
> If there's interest in supporting this feature I can help since we've
> formalized most of BasicAA. I can easily verify if proposed changes
> are correct. (I'll release the code soon).
> 
> Nuno
> 
> 
> Quoting Björn Pettersson A <bjorn.a.pettersson at ericsson.com>:
> 
> > Hi Nuno.
> > I can't answer your question, but I know that Mikael Holmén wrote a
> > trouble report about problems in GVN related to objects larger than
> > half of address space:
> >   https://bugs.llvm.org/show_bug.cgi?id=34344
> >
> > It ended up in a long discussion with Eli Friedman, and then I think
> > we just left it as an open trouble report.
> >
> > /Björn
> >
> >> -----Original Message-----
> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> Nuno
> >> Lopes via llvm-dev
> >> Sent: den 8 november 2017 18:24
> >> To: llvm-dev at lists.llvm.org
> >> Subject: [llvm-dev] Is it ok to allocate > half of address space?
> >>
> >> Hi,
> >>
> >> I was looking into the semantics of GEP inbounds and some BasicAA
> >> rules and I'm wondering if it's valid in LLVM IR to allocate more than
> >> half of the address space with a global variable or an alloca.
> >> If that's a scenario want to consider, then we have problems :)
> >>
> >> Consider this C code (32 bits):
> >> #include <string.h>
> >>
> >> char obj[0x80000008];
> >>
> >> char f() {
> >>    char *p = obj + 0x79999999;
> >>    char *q = obj + 0x80000000;
> >>    *q = 1;
> >>    memcpy(p, "abcd", 4);
> >>    return *q;
> >> }
> >>
> >>
> >> Clearly the stores alias, and the memcpy should override the value
> >> written by "*q = 1".
> >>
> >> I dunno if this is legal in C or not, but the IR produced by clang
> >> looks like (32 bits):
> >>
> >> @obj = common global [2147483656 x i8] zeroinitializer, align 1
> >>
> >> define signext i8 @f() {
> >>    store i8 1, i8* getelementptr inbounds (i8, i8* getelementptr
> >> inbounds ([2147483656 x i8], [2147483656 x i8]* @obj, i32 0, i32 0),
> >> i32 -2147483648), align 1
> >>    call void @llvm.memcpy.p0i8.p0i8.i32(i8* getelementptr inbounds
> >> ([2147483656 x i8], [2147483656 x i8]* @obj, i32 0, i32 2040109465),
> >> i8* getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32 0),
> >> i32 4, i32 1, i1 false)
> >>    %1 = load i8, i8* getelementptr inbounds (i8, i8* getelementptr
> >> inbounds ([2147483656 x i8], [2147483656 x i8]* @obj, i32 0, i32 0),
> >> i32 -2147483648), align 1
> >>    ret i8 %1
> >> }
> >>
> >> With -O2, the store to q gets forwarded, and so we get "ret i8 1".
> >> So, BasicAA concluded that p and q don't alias. The culprit is an
> >> overflow in BasicAAResult::isGEPBaseAtNegativeOffset().
> >>
> >> So my question is do we care about this use case where a single
> >> allocation can take more than half of the address space?
> >>
> >> Thanks,
> >> Nuno