On 1/17/2013 11:33 PM, Owen Anderson wrote:> > Almost certainly, the compiler can't tell that the load from the struct > (to get the array pointer) doesn't alias with the stores to the array > itself. This is exactly the kind of thing that type-based alias > analysis (-fstrict-aliasing) can help with. Use with caution, as it > can break some type-unsafe idioms.The problem is actually the stores to out->data. While "d" and "out" are restricted pointers, it tells us nothing about the relation between "d->data" and "out->data", since the "data" member is a pointer itself. Since both "d->data" and "out->data" are both of type double, the type-based alias analysis won't help. In the case when you pass "double*" to the function, the restrict keyword tells us that the arrays of doubles themselves do not alias, which allows the compiler to infer that the loads and stores in the loop do not depend on each other. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Fri, Jan 18, 2013 at 6:36 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> Since both "d->data" and "out->data" are both of type double, the > type-based alias analysis won't help.Right, I see. Is there any other way to solve this? As the last resort, I was considering silently transforming each Array argument into separate data and metadata arguments, but that would certainly add other complications I'd rather avoid. I was also think ing a hypothetical LLVM-based Fortran compiler would be the model to aim for, where they have dimension-aware arrays that never alias (AFAIK?). I wonder how one would solve that problem there. Dimitri. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130118/f7661f13/attachment.html>
On Fri, Jan 18, 2013 at 9:11 AM, Dimitri Tcaciuc <dtcaciuc at gmail.com> wrote:> Right, I see. Is there any other way to solve this?And I suppose one would be to write a specialized aliasing analysis pass which would return "NoAlias" if the "data" pointer loads come from different Array structs? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130118/7ce04ec4/attachment.html>
On 1/18/2013 11:11 AM, Dimitri Tcaciuc wrote:> > Right, I see. Is there any other way to solve this? As the last resort, > I was considering silently transforming each Array argument into > separate data and metadata arguments, but that would certainly add other > complications I'd rather avoid.Depends on what information you have available. If all you have is the LLVM IR, then the only universal solution that I can think of is interprocedural analysis, where you would track the pointer values, and potentially determine that they never point to overlapping memory areas.> I was also think ing a hypothetical LLVM-based Fortran compiler would be > the model to aim for, where they have dimension-aware arrays that never > alias (AFAIK?). I wonder how one would solve that problem there.I think the proper way would be to use metadata after all, and have some alias analysis that could understand it. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation