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

Tyler Kenney via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 1 08:13:28 PDT 2016



Hello all,

I am developing an out-of-tree backend for a unique simd processor and I'm
looking for a bit of help. In my current design, it's possible for a case
to arise where I decide during instruction legalization that a fixed-sized
array of vectors which has been initially allocated on the stack needs to
be lowered into the vector register file. I have this design working for
the case where the stack object's lifetime resides entirely within a single
basic block: I start with an undef node to represent the set of registers
to which the buffer is allocated, and replace stores to the buffer with
insert_subvector's and replace loads with extract_subvector's.

I'm now looking at generalizing the design for the case where the stack
object's lifetime spans across 2 or more basic blocks and am hoping someone
from the community will be able to offer a little insight so that if there
are major issues here I can find out sooner rather than later. I'd like to
add this newly-created big vector value as an input reg for all BBs that
reference the original stack object but do not contain it's LIFETIME_START
node, and I'd like to add it as an output reg for all BBs that reference
the original stack object but do not contain it's LIFETIME_END node. I can
create Copy From/ToReg nodes easily enough and I think I can get the reg
number using MachineRegisterInfo::createVirtualRegister(). But I don't
quite understand how I set up the mapping from the new outputs of some BBs
to the new inputs of other BBs. I dug through the code and it looks like I
may be able to do this by manipulating
FunctionLoweringInfo::PHINodesToUpdate and/or directly adding PHI
instructions to the MachineBasicBlock's. Here are my specific questions:

	1.) Are there any existing targets that manipulate BB input/output
regs that I could look at as an example? Or can anyone provide a brief
explanation of how to accomplish this?
	2.) I realize that the design I've described might sound a little
bizarre, but does it at least sound possible? I can provide a little more
detail and am open to suggestions if there are alternative designs I'm
overlooking.


Thanks in advance,

Tyler
Logic Design Engineer
IBM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/c0bcc3a5/attachment.html>


More information about the llvm-dev mailing list