<html><body><p>Thanks Tim. I'll work on a design that does the proper CFG analysis so I know which BBs to add the live-ins & outs to.<br><br>Can you or anyone else comment on the process of adding the live-ins & outs to each basic-block that needs them? Like I said, I can create the nodes easily enough but I don't quite understand how to adjust the PHI nodes to be sure the new inputs & outputs are mapped to each other appropriately. Sounds like it's safe to assume there's no other target I can look to for an example on this?<br><br>Tyler<br><br><br><br><img width="16" height="16" src="cid:1__=0ABBF555DFC8C45D8f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Tim Northover ---06/01/2016 02:42:20 PM---Hi Tyler, On 1 June 2016 at 11:27, Tyler Kenney <tjkenney@u"><font color="#424282">Tim Northover ---06/01/2016 02:42:20 PM---Hi Tyler, On 1 June 2016 at 11:27, Tyler Kenney <tjkenney@us.ibm.com> wrote:</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Tim Northover <t.p.northover@gmail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Tyler Kenney/Marlborough/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">LLVM Developers Mailing List <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">06/01/2016 02:42 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [llvm-dev] Adding BB input/output registers during ISel</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>Hi Tyler,<br><br>On 1 June 2016 at 11:27, Tyler Kenney <tjkenney@us.ibm.com> wrote:<br>> 1.) Can you provide another example of a BB that would have an unreferenced live-in live-out var without making a function call?<br><br>The function call was just there to make sure the block wasn't removed<br>as dead code. The same issue applies to all basic blocks: any block<br>control passes through from a definition to a use has to have the vreg<br>marked as live.<br><br>> 2.) What is the problem with having a basic-block that ignores an unreferenced live-in, live out? I am sure that will cause an issue, but I'd like to understand a little better what the issue will be. To put it another way, what would happen if I was somehow able to surgically remove res as a live-in & live-out from the BB calling bar() in your example, but change nothing else?<br><br>I'm afraid I don't know specifically what *would* go wrong, but the<br>malformed data-flow information could confuse any inter-block analysis<br>that happens after your pass. Register allocation might decide to<br>reuse (and clobber) the vector register in the unmarked middle block,<br>for example.<br><br>> 3.) Just to make sure I understand, I assume you would say the following has the opposite problem:<br>><br>> I'd like to add this newly-created big vector value as an input reg for all BBs in the func except the one that contains its LIFETIME_START node, and I'd like to add it as an output reg for all BBs in the func except the one that does not contain its LIFETIME_END node.<br>><br>> That has the problem that I may add the inputs & outputs to BBs that shouldn't have them, right? Again, do you know how this issue would manifest itself?<br><br>Extra live-ins and outs are probably less harmful since they just<br>restrict what's allowed. The big problem with this second scenario is<br>the same as the first: real uses of this register are unmarked at BB<br>edges.<br><br>> 4.) More generic LLVM question here: is there any sort of convention for distinguishing between live-ins/outs for a func and live-ins/outs for a BB? It seems like most of the time I see those terms they're referring to function live-ins/outs, but not always.<br><br>I don't think so. They're basically the same thing just at different levels.<br><br>Cheers.<br><br>Tim.<br><br></tt><br><BR>
</body></html>