[LLVMdev] More Qs about llvm IR to access struct fields

[Rodney M. Bates]

OK, Thanks.  I will plan to use 3), as it is the way I get it from my front-end.

On 04/18/2014 10:37 AM, Dan Gohman wrote:
>
>
>
> On Fri, Apr 18, 2014 at 5:40 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote:
>
>     On 4/17/2014 2:41 PM, Rodney M. Bates wrote:
>
>
>         Question 1:
>         Does this choice affect the optimization possibilities?
>
>
>     Depends on how advanced the alias analysis is these days (it is mostly the alias analysis that could suffer).  I haven't looked into the AA code much, but from what I remember, it could be affected by how the data addresses are constructed.  Look into the TBAA metadata and whether there is any expectation of correlation between the GEP structure and the TBAA information. (Sorry, I don't have exact answers off the top of my head.)
>
>
> LLVM's builtin type system provides MustAlias information, and TBAA metadata provides NoAlias information. The two complement each other, and do not conceptually interact (though they do interact in practice somewhat due to sharing the same AliasAnalysis API).
>
> If two memory accesses have the same base and the same gep indices, then they're accessing the same memory, and you can do the MustAlias family of optimizations -- eliminating one of the accesses. But if two memory accesses have different bases or different gep indices, you can't immediately prove anything.
>
> If two memory accesses have TBAA tags which indicate non-aliasing, then they're accessing different memory, and you can do the NoAlias family of optimizations -- reordering the accesses with respect to each other. But if the two memory accesses have the same tag, you can't immediately prove anything.
>
> The AliasAnalysis difference between 1) and 2) above is that 1) has stronger LLVM type information, so it has more MustAlias information. However, these days BasicAA can compute MustAlias information by analyzing everything as byte offsets too, so there's probably no difference in practice.
>
> The main practical advantage of 1) is that it gives SROA a suggestion for how to split up an aggregate in memory. There's no semantic difference, and in theory SROA could infer where the fields are by looking at the actual memory access (and in theory this would make it more powerful), but relying on the type is a convenient heuristic.
>
> 3) is less nice because the load is wider, which could produce false dependencies if there are nearby accesses to other fields of the struct. But the optimizer will probably convert 3) into something like 2) or 1) pretty quickly, so it's probably not hugely different in practice.
>
> Dan
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
Rodney Bates
rodney.m.bates at acm.org