<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 13, 2017 at 5:13 PM, Michael Kruse via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">2017-10-14 1:29 GMT+02:00 Saito, Hideki via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>:<br>
> I'm also sorry that I'm not commenting on the main part of your RFC in this reply. I just want to focus on<br>
> one thing here.<br>
><br>
> Proposed Loop Optimization Framework<br>
> ------------------------------<wbr>------<br>
> Only the architecture is outlined here. The reasons for them can be<br>
> found in the "rationales" section below.<br>
><br>
> A) Preprocessing<br>
> Make a copy of the entire function to allow transformations only for<br>
> the sake of analysis.<br>
><br>
> Before we started our journey into VPlan-based vectorization approach, we explicitly asked about modifying the IR for<br>
> the sake of vectorization analysis ----- general consensus in LLVM-DEV was "that's a bad idea". We thought so, too.<br>
> That's the reason VPlan has its own local data structure that it can play with.<br>
><br>
> Making a copy of the entire function is far worse than copying a loop (nest). Unless the community mindset has dramatically<br>
> changed since ~2yrs ago, it's unlikely that you'll get overwhelming support on "copy the entire function" before the decision<br>
> to transform is taken. So, if this part is optional, you may want to state that.<br>
><br>
> Having said that, in <a href="https://reviews.llvm.org/D38676" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D38676</a>, we are introducing concepts like VPValue, VPUser, and VPInstruction,<br>
> in order to manipulate and interact with things that didn't come from the IR of the original loop (nest). As such, I can see<br>
> why you think "a playground copy of IR" is beneficial. Even before reading your RFC, I was actually thinking that someone<br>
> else may also benefit from VPValue/VPUser/VPInstruction-<wbr>like concept for the analysis part of some heavy-weight transformations.<br>
> Ideally, what we wanted to do was to use LLVM's Value class hierarchy if we could generate/manipulate "abstract Instructions"<br>
> w/o making them parts of the IR state, instead of creating our own light-weight VPValue/VPUser/VPInstruction classes.<br>
> If anyone has better ideas in this area, we'd like to listen to. Please reply either to this thread or through the code review<br>
> mentioned above.<br>
<br>
</span>Thank you for bringing in results from previous discussions. The only<br>
resource I was aware of was the EuroLLVM talk where I got the<br>
impression this was done for performance reasons. Do you recall the<br>
arguments why it was considered a bad idea?<br>
<br>
I understand that modifying the IR speculatively might not the best<br>
thing to do. However, I also think that another meta-layer<br>
representing instructions increases complexity and duplicates<br>
algorithms when we could just reuse the data structures and algorithms<br>
that already exist and have matured.<br></blockquote><div><br></div><div>I have a feeling that the LLVM LoopInfo/Loop datastructure, which only focus on the CFG, is not sufficient.</div><div>And we build extra layer upon the LLVM LoopInfo/Loop, e.g. Scop in Polly and the Hierarchical CFG in VPlan (right?).</div><div><br></div><div>Maybe we can have layers between the existing LoopInfo/Loop and VPlan/SCoP:</div><div><br></div><div>1. LoopInfo/Loop</div><div>2. LoopInfo/Loop + Hierarchical CFG</div><div>3. LoopInfo/Loop + Hierarchical CFG + Memory Accesses description<br></div><div>4. VPlan/Scop</div><div><br></div><div>I think layer 2 and 3 will be very useful even outside of Polly and VPlan</div><div><br></div><div>Hongbin</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Michael<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>