[llvm-dev] Adding BB input/output registers during ISel

[Tyler Kenney via llvm-dev]

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.

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?

Tyler





From:	Tim Northover <t.p.northover at gmail.com>
To:	Tyler Kenney/Marlborough/IBM at IBMUS
Cc:	LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
Date:	06/01/2016 02:42 PM
Subject:	Re: [llvm-dev] Adding BB input/output registers during ISel



Hi Tyler,

On 1 June 2016 at 11:27, Tyler Kenney <tjkenney at us.ibm.com> wrote:
> 1.) Can you provide another example of a BB that would have an
unreferenced live-in live-out var without making a function call?

The function call was just there to make sure the block wasn't removed
as dead code. The same issue applies to all basic blocks: any block
control passes through from a definition to a use has to have the vreg
marked as live.

> 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?

I'm afraid I don't know specifically what *would* go wrong, but the
malformed data-flow information could confuse any inter-block analysis
that happens after your pass. Register allocation might decide to
reuse (and clobber) the vector register in the unmarked middle block,
for example.

> 3.) Just to make sure I understand, I assume you would say the following
has the opposite problem:
>
>  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.
>
> 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?

Extra live-ins and outs are probably less harmful since they just
restrict what's allowed. The big problem with this second scenario is
the same as the first: real uses of this register are unmarked at BB
edges.

> 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.

I don't think so. They're basically the same thing just at different
levels.

Cheers.

Tim.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/e3f27393/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/e3f27393/attachment.gif>