> There are essentially two ways to "solve" this issue: one is > type-based alias analysis, i.e. assuming "double" and "int" don't > alias; LLVM doesn't implement this at the moment. The other is to > attempt to analyze the loop and prove that %indvar.i is never > negative; LLVM doesn't implement anything like this at the moment > either. > > -EliActually I think it's much simpler than that... http://llvm.org/releases/1.3/docs/AliasAnalysis.html#basic-aa it says says "Different fields of a structure do not alias." This is the case here : we have two different fields of a struct however it mistakenly thinks they alias.
On Wed, Jun 16, 2010 at 11:14 PM, Pierre C <lists at peufeu.com> wrote:>> There are essentially two ways to "solve" this issue: one is >> type-based alias analysis, i.e. assuming "double" and "int" don't >> alias; LLVM doesn't implement this at the moment. The other is to >> attempt to analyze the loop and prove that %indvar.i is never >> negative; LLVM doesn't implement anything like this at the moment >> either. >> >> -Eli > > Actually I think it's much simpler than that... > > http://llvm.org/releases/1.3/docs/AliasAnalysis.html#basic-aa > > it says says "Different fields of a structure do not alias." > > This is the case here : we have two different fields of a struct however it > mistakenly thinks they alias.Consider a case like the following: struct X { int a; int b[10]; }; int f(struct X* a) { a->b[-1] = 1; return a->a; } This is technically illegal code, but various programs depend on constructs like this working. -Eli
On Jun 17, 2010, at 12:22 AM, Eli Friedman wrote:> On Wed, Jun 16, 2010 at 11:14 PM, Pierre C <lists at peufeu.com> wrote: >>> There are essentially two ways to "solve" this issue: one is >>> type-based alias analysis, i.e. assuming "double" and "int" don't >>> alias; LLVM doesn't implement this at the moment. The other is to >>> attempt to analyze the loop and prove that %indvar.i is never >>> negative; LLVM doesn't implement anything like this at the moment >>> either. >>> >>> -Eli >> >> Actually I think it's much simpler than that... >> >> http://llvm.org/releases/1.3/docs/AliasAnalysis.html#basic-aa >> >> it says says "Different fields of a structure do not alias." >> >> This is the case here : we have two different fields of a struct however it >> mistakenly thinks they alias. > > Consider a case like the following: > struct X { int a; int b[10]; }; > int f(struct X* a) { a->b[-1] = 1; return a->a; } > > This is technically illegal code, but various programs depend on > constructs like this working. >Those programs are buggy and should be fixed.
On Thu, Jun 17, 2010 at 12:22 AM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Wed, Jun 16, 2010 at 11:14 PM, Pierre C <lists at peufeu.com> wrote: >>> There are essentially two ways to "solve" this issue: one is >>> type-based alias analysis, i.e. assuming "double" and "int" don't >>> alias; LLVM doesn't implement this at the moment. The other is to >>> attempt to analyze the loop and prove that %indvar.i is never >>> negative; LLVM doesn't implement anything like this at the moment >>> either. >>> >>> -Eli >> >> Actually I think it's much simpler than that... >> >> http://llvm.org/releases/1.3/docs/AliasAnalysis.html#basic-aa >> >> it says says "Different fields of a structure do not alias." >> >> This is the case here : we have two different fields of a struct however it >> mistakenly thinks they alias. > > Consider a case like the following: > struct X { int a; int b[10]; }; > int f(struct X* a) { a->b[-1] = 1; return a->a; } > > This is technically illegal code, but various programs depend on > constructs like this working.I don't know if it's illegal, but this is how libstdc++'s string implementation finds its header data. std::string stores a pointer directly to the character data (making subscripting slightly faster), and then subtracts the size of the header when it needs to do any bookkeeping. Do you have a reference to the standard that makes it undefined?