Nuno Lopes via llvm-dev
2017-Nov-08 18:13 UTC
[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
Björn Pettersson A via llvm-dev
2017-Nov-08 18:30 UTC
[llvm-dev] Is it ok to allocate > half of address space?
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
David Majnemer via llvm-dev
2017-Nov-08 18:53 UTC
[llvm-dev] Is it ok to allocate > half of address space?
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). On Wed, Nov 8, 2017 at 10:30 AM, Björn Pettersson A via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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 > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171108/928074c2/attachment.html>