<div dir="ltr">> 

Ah, that's important information I didn't have.  Thank you!<br><br>No problem, glad to help! <br><br>To the rest of your thoughts, I certainly agree. One interesting question is why LAA<br>didn't use DA at all. Other than that, note that LAA is quite specialized, namely for<br>loop vectorization. Actually, it's even more specific. For innermost loop vectorization.<br><div>That affects the design. It might had been easier to create this specialized tool than</div><div>extending a general one (if that was a good path to follow is another topic).</div><div><br></div><div>> But yet they are intimately related in that the kind of information you<br>> want to know statically and dynamically is the same.  I wonder what it<br>> would take to extend DA to generate runtime checks if it can't prove<br>> independence.</div><div><br></div><div>Indeed, but again, IMHO unifying them is neither easy nor does it make sense.</div><div>They do fundamentally the same thing but their directions are very different.</div><div><br></div><div>So, I see two options:</div><div><br></div><div>a) As you said<br><br>>  I wonder what it would take to extend DA to generate runtime checks if it can't prove independence.</div><div><br>Personally, I see potential but neither do I know what it would take. Since this is something that I'm</div><div>currently thinking of, I would be more than interested to discuss it extensively.</div><div><br></div><div>In any case, I would strongly prefer that we don't follow the LAA path, since I don't think it has potential</div><div>anyway. I think that we should try to find a way to extend it that is also based on strong theoretical foundation</div><div>and maintains the high quality of code.<br><br>b) Extend LAA to do static checks<br><br>The question here is though: Why do that? As I said, it doesn't seem to have potential and I believe that people</div><div>working on vectorizers (either LLVM's current one or external like e.g. RV and VPlan) don't do either.<br><br>Tell me what you think and I'm looking forward to more people jumping in.<br><br>- Stefanos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Στις Τρί, 7 Ιουλ 2020 στις 11:11 μ.μ., ο/η David Greene <<a href="mailto:david.greene@hpe.com">david.greene@hpe.com</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Stefanos Baziotis via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
> Their most important difference is that DA is used for compile-time /<br>
> static checks while LAA is mainly used for generating run-time checks.<br>
<br>
Ah, that's important information I didn't have.  Thank you!<br>
<br>
> Now, as for unifying them, if we mean something other than just putting<br>
> them in the same file, I don't think it can happen.<br>
> IMHO they're way more apart than it initially seems.<br>
<br>
But yet they are intimately related in that the kind of information you<br>
want to know statically and dynamically is the same.  I wonder what it<br>
would take to extend DA to generate runtime checks if it can't prove<br>
independence.<br>
<br>
The thing I fear is one or the other being enhanced to resolve more<br>
things statically without the other getting the same improvements.  Then<br>
some passes benefit and others don't and it won't be clear why.  The<br>
same could happen with enhancement to dynamic checking (if it were added<br>
to DA).<br>
<br>
                       -David<br>
</blockquote></div>