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.
>> 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. >>Actually if you want to do bit-casting in C the usual way is to very carefully use an union which informs the compiler that there will be aliasing...> Those programs are buggy and should be fixed.Totally agree. Making such ugly things work means lots of optimizations can't be performed. I wonder if llvm intentionnally generates this spurious alias (to make badly written code work) or is it just the optimizer not being smart enough yet ?...
On Jun 17, 2010, at 9:42 AM, Pierre C wrote:> >>> 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. >>> > > Actually if you want to do bit-casting in C the usual way is to very carefully use an union which informs the compiler that there will be aliasing... >Quite right. Unfortunately, Eli is correct that there is a large codebase out there that uses less friendly idioms. It's getting better over time as people fix the issues (perhaps wishful thinking on my part), but it is still a "gotcha" we need to be aware of and consider when we make more aggressive optimizations.> Making such ugly things work means lots of optimizations can't be performed. >Exactly. To elaborate on my probably-too-curt initial response, I believe that optimizations should not be constrained by non-comformant code. That said, I also believe we should be as friendly as we can in helping people find and fix these issues. Tracking down a bug like that in user code is an absolute nightmare. Specifically, we should issue good diagnostics for problems of this sort, from the compiler and/or from the static analyzer, whenever possible.> I wonder if llvm intentionnally generates this spurious alias (to make badly written code work) or is it just the optimizer not being smart enough yet ?...I'm not 100% sure, but I suspect it's the latter. -Jim