<div dir="ltr">I don't think it is reasonable because pointer subtraction stops working with objects that large (i.e. taking the difference and adding it back to the base is nonsensical).</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 8, 2017 at 10:30 AM, Björn Pettersson A via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The example in <a href="https://bugs.llvm.org/show_bug.cgi?id=34344" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_<wbr>bug.cgi?id=34344</a> is of course a reduced test case.<br>
The problem was detected a runtime failures in one of our regression tests for large memcpy from one address space to another.<br>
<br>
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).<br>
<br>
/Björn<br>
<div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: Nuno Lopes [mailto:<a href="mailto:nunoplopes@sapo.pt">nunoplopes@sapo.pt</a>]<br>
> Sent: den 8 november 2017 19:13<br>
> To: Björn Pettersson A <<a href="mailto:bjorn.a.pettersson@ericsson.com">bjorn.a.pettersson@ericsson.<wbr>com</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>; Mikael Holmén <<a href="mailto:mikael.holmen@ericsson.com">mikael.holmen@ericsson.com</a>>;<br>
> <a href="mailto:efriedma@codeaurora.org">efriedma@codeaurora.org</a><br>
> Subject: Re: [llvm-dev] Is it ok to allocate > half of address space?<br>
><br>
> Many thanks for the pointer!  I missed that bug report since the title<br>
> was about GVN.<br>
><br>
> If there's interest in supporting this feature I can help since we've<br>
> formalized most of BasicAA. I can easily verify if proposed changes<br>
> are correct. (I'll release the code soon).<br>
><br>
> Nuno<br>
><br>
><br>
> Quoting Björn Pettersson A <<a href="mailto:bjorn.a.pettersson@ericsson.com">bjorn.a.pettersson@ericsson.<wbr>com</a>>:<br>
><br>
> > Hi Nuno.<br>
> > I can't answer your question, but I know that Mikael Holmén wrote a<br>
> > trouble report about problems in GVN related to objects larger than<br>
> > half of address space:<br>
> >   <a href="https://bugs.llvm.org/show_bug.cgi?id=34344" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_<wbr>bug.cgi?id=34344</a><br>
> ><br>
> > It ended up in a long discussion with Eli Friedman, and then I think<br>
> > we just left it as an open trouble report.<br>
> ><br>
> > /Björn<br>
> ><br>
> >> -----Original Message-----<br>
> >> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@<wbr>lists.llvm.org</a>] On Behalf Of<br>
> Nuno<br>
> >> Lopes via llvm-dev<br>
> >> Sent: den 8 november 2017 18:24<br>
> >> To: <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> >> Subject: [llvm-dev] Is it ok to allocate > half of address space?<br>
> >><br>
> >> Hi,<br>
> >><br>
> >> I was looking into the semantics of GEP inbounds and some BasicAA<br>
> >> rules and I'm wondering if it's valid in LLVM IR to allocate more than<br>
> >> half of the address space with a global variable or an alloca.<br>
> >> If that's a scenario want to consider, then we have problems :)<br>
> >><br>
> >> Consider this C code (32 bits):<br>
> >> #include <string.h><br>
> >><br>
> >> char obj[0x80000008];<br>
> >><br>
> >> char f() {<br>
> >>    char *p = obj + 0x79999999;<br>
> >>    char *q = obj + 0x80000000;<br>
> >>    *q = 1;<br>
> >>    memcpy(p, "abcd", 4);<br>
> >>    return *q;<br>
> >> }<br>
> >><br>
> >><br>
> >> Clearly the stores alias, and the memcpy should override the value<br>
> >> written by "*q = 1".<br>
> >><br>
> >> I dunno if this is legal in C or not, but the IR produced by clang<br>
> >> looks like (32 bits):<br>
> >><br>
> >> @obj = common global [2147483656 x i8] zeroinitializer, align 1<br>
> >><br>
> >> define signext i8 @f() {<br>
> >>    store i8 1, i8* getelementptr inbounds (i8, i8* getelementptr<br>
> >> inbounds ([2147483656 x i8], [2147483656 x i8]* @obj, i32 0, i32 0),<br>
> >> i32 -2147483648), align 1<br>
> >>    call void @llvm.memcpy.p0i8.p0i8.i32(i8* getelementptr inbounds<br>
> >> ([2147483656 x i8], [2147483656 x i8]* @obj, i32 0, i32 2040109465),<br>
> >> i8* getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32 0),<br>
> >> i32 4, i32 1, i1 false)<br>
> >>    %1 = load i8, i8* getelementptr inbounds (i8, i8* getelementptr<br>
> >> inbounds ([2147483656 x i8], [2147483656 x i8]* @obj, i32 0, i32 0),<br>
> >> i32 -2147483648), align 1<br>
> >>    ret i8 %1<br>
> >> }<br>
> >><br>
> >> With -O2, the store to q gets forwarded, and so we get "ret i8 1".<br>
> >> So, BasicAA concluded that p and q don't alias. The culprit is an<br>
> >> overflow in BasicAAResult::<wbr>isGEPBaseAtNegativeOffset().<br>
> >><br>
> >> So my question is do we care about this use case where a single<br>
> >> allocation can take more than half of the address space?<br>
> >><br>
> >> Thanks,<br>
> >> Nuno<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>