<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 14, 2013, at 12:34 PM, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On 14 February 2013 17:46, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank">aschwaighofer@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">The existing implementation already relies on runtime checks (it has to make sure that an unknown object and a known object do not overlap). Yes, AA will conservatively return MayAlias/PartialAlias if it does not know two objects. You just have to make sure that you actually query it with that unknown object.<br>
</div></blockquote><div><br></div><div>I was expecting this, and I'm planning to be extra conservative to begin with. So, for now, MayAlias and PartialAlias are reasons to stop trying. Once we can get the code to understand basic independent objects inside a structure, we can specialize for the other cases.</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>Okay. But understand that LLVM IR semantics does not give you much leeway in "understanding independent objects inside a structure". That is what you need TBAA for.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Say you have three access in your program: one has underlying object A, one has underlying object B, and one has an unknown underlying object U. If you just rely on AA, you have to query both pairs ((Access A), (Access O)) and ((Access B), (Access O)).<br>
</div></blockquote><div><br></div><div>My current proposal does that if the unknown underlying object can be retrieved from GetUnderlyingObjects(). If unknown means the array is empty, than maybe we should add a special condition to bail, at least for now.</div>
<div><br></div></div></div></div></blockquote><div><br></div>Yes, I was just being verbose.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div>alias((&S.a[99], 4xsizeof(int)), &S.b[0], 4xsizeof(int)) == partial alias</div></div></blockquote><div><br>
</div><div>That's great! So I can rely on AA to do the hard work for me, just need to give it the correct Size.</div><div><br></div></div></div></div></blockquote></div>I think you read to quickly :). Partial alias is bad. You want NoAlias. I am warning that if we use alias analysis the way we have to we might not get the answer we would like to see.</div>
</div></blockquote><div><br></div><div><br></div><div>I meant that I can bail on any slightly dangerous case for now, and add special cases later on PartialAlias, if I know how to change the induction range to make it not alias while vectorized.</div>
<div><br></div></div></div></div></blockquote><div><br></div>Yes. Scrap what I said I was over thinking the original example, we should be fine.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div style="word-wrap:break-word"><div>AA will analyze address computations (it looks at the existing IR which still has the scalar bounds):<br>
</div><div><br></div><div>(&S.a[0.99], sizeof(int)*VF) and (&S.b[0], sizeof(int)*VF)</div><div><br></div><div>and there is an overlap due to the increased access size.</div></div></blockquote><div><br></div><div>
Since this is still in the legalization phase, we can't have access (nor create new) vector IR to make the alias analysis work correctly.</div><div><br></div><div>For instance the code:</div><div><br>
</div><div>for (k: 0..100) {</div><div> S.a[100-k] = S.b[k] + 1;</div><div>}</div><div><br></div><div>Will be PartialAlias with the "pretend-vectorization-alias-analysis", while you could vectorize by reversing S.b and changing the start of the iteration.</div>
<div><br></div><div>But in cases like that, I'd rather add as a special case (possibly adding more types of reduction), than trying to get it right with the first and generic implementation.<br></div><div><br></div><div style="">
I think I'll create a few examples that should and should not vectorize, so I can have a clearer view of how to apply that model to code.</div><div><br></div></div></div></div></blockquote><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>cheers,</div><div>--renato</div></div></div></div>
</blockquote></div><br></body></html>