<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><i><font size="2" face="monospace, monospace"><b>Vivek Pandya</b></font></i><div><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 23, 2016 at 10:28 PM, Krzysztof Parzyszek <span dir="ltr"><<a href="mailto:kparzysz@codeaurora.org" target="_blank">kparzysz@codeaurora.org</a>></span> wrote:<br><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"><span class="">On 3/1/2016 11:26 AM, vivek pandya via llvm-dev wrote:<br>
<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">
<br>
Still I am looking for feedback on RDF part and also if some one is<br>
willing to mentor me.</blockquote></span></blockquote><div>Hello Krzysztof Parrzyszek,</div><div><br></div><div>I switched to other topic as I felt I don't have enough experience in various backends. I also not tried to ask for guidance after I observed long gap. So as far as GSoC is concerned it is not possible to make a solid proposal with in a day. I need to read the papers related to RDF stuffs in LLVM and also write up the whole initial search I did. But still I will keep this mail in my mind and I will notify you if I work some thing on this topic during my free time.</div><div><br></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"><span class=""></span>
Hi Vivek,<br>
Sorry, I missed this email.  I wrote the RDF stuff and I'd be happy to help you out with it if you are interested.<br>
<br>
The idea was to have a utility class that would represent the data flow between registers.  The registers could be a mixture of virtual and physical, although the main application would be to use it on a post-RA code.  I decided against having it as a part of the pass manager, because the user does not have any direct control over the creation and invalidation of analyses, at least in the current version of the pass manager.  This does not mean that it cannot (or shouldn't) be used in an analysis, just that it should also be available as a standalone utility.<br>
<br>
<br>
The missing bits are:<br>
<br>
1. Handling of regmasks<br>
This shouldn't be too hard.  All reference nodes (except those in phi nodes) have a pointer to the machine operand, from which the actual register is obtained.  Regmasks are different, since a single operand references multiple registers at once.  The way to handle them would be to treat a regmask as a register of its own that is aliased with the registers, whose clobbering it represents.<br>
<br>
2. Recomputing liveness information on instruction level.<br>
The MI-level IR uses implicit operands to keep track of the liveness of aliased registers. These implicit operands serve no other purpose, but they may introduce apparent dependencies (that do not, in fact exist). RDF will ignore these implicit operands when constructing the DFG, and optimizations using RDF could produce code where the liveness information carried by these operands is no longer valid (the same goes for <kill> flags).  This information would need to be recomputed.  There is some code in there that does that for the <kill> flags, but it does not deal with the implicit operands at all.<br>
<br></blockquote><div>The only thing I understand here is 3 point because some thing similar I have thought.</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">
3. Making it work with ther targets.<br>
RDF is intended to handle code that contains both physical and virtual registers on any target, but it has only been tested (in some capacity) on post-RA code and only on Hexagon.  Making it fully target-independent would involve testing it with other targets.<br>
- There are "copy propagation" and "dead code elimination" passes that use RDF.  Both are also meant to be target-independent and could serve as a testing tool.<br>
- RDF liveness would need to be verified to work on other targets.  It is meant to recalculate block live-ins.<br>
<br>
4. It is unknown what RDF will do with bundles.<br>
In theory, it should use the summary information from each bundle (without looking inside of bundles), but I have no idea whether there are any cases that would break it.  There is nothing to represent the data flow within a bundle: besides not having any representation for it now, the actual data flow there may be highly target-dependent.  This is more of a hypothetical question, at least for now, since it may be fairly complex to design and implement.<span class=""><font color="#888888"><br>
<br>
<br></font></span></blockquote><div>Thanks for reply !</div><div><br></div><div>Sincerely,</div><div>Vivek </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"><span class=""><font color="#888888">
-Krzysztof<br>
<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation<br>
</font></span></blockquote></div><br></div></div>