[PATCH] MIR Serialization: Serialize MBB operands.
Duncan P. N. Exon Smith
dexonsmith at apple.com
Tue Jun 23 12:43:23 PDT 2015
> On 2015-Jun-22, at 11:38, Alex Lorenz <arphaman at gmail.com> wrote:
> Hi dexonsmith, bob.wilson, bogner,
> This patch is based on a previous serialization patch that serializes null register operands (http://reviews.llvm.org/D10580).
> This patch serializes machine basic block operands.
> The following syntax is used for basic block operands:
> The name is printed when the machine basic block has a name, i.e. when its basic block has a name. Otherwise, a number is printed, which is just an index into a list of machine basic blocks for that function.
> JG_1 %bb.if.cond
> JG_1 %bb.2
This is ambiguous in general. IIUC, it's legal for two different
`MachineBasicBlock`s to point at the same `BasicBlock` (see, e.g.,
`BranchFolder::SplitMBBAt()`), so the name isn't a sufficient identifier.
I'm not such a big fan of your numbered identifiers either, since they're
going to be hard to read, the numbering isn't explicit in the source, and
the numbering is fragile (removing a basic block in the middle changes
all the numbers following).
Here's a different straw man proposal (I don't love it, so I hope you can
refine it to something better).
First, change the `name:` field to include an ID number. Suppose you
have two BBs, %then and %else. %then has two MBBs. You'd get something
like the following:
- name: 0.then
- name: 0.else
- name: 1.then
The syntax is `<num> ['.' <bb-name>]`. (Maybe the `<num>` should be
specified in a separate field?)
Second, change the references to use both these numbers and the names.
Maybe, for these:
Unnamed basic blocks fall out naturally as:
%bb.0 ; reference to the first unnamed basic block
%bb.1 ; reference to the second unnamed basic block
These aren't alternate names, these are the only names. And the `0` and
`1` are somehow defined explicitly in MIR.
Thoughts? Other ideas?
> rL LLVM
> EMAIL PREFERENCES
More information about the llvm-commits