[llvm-commits] [llvm] r128537 - in /llvm/trunk: docs/tutorial/ examples/BrainF/ examples/Kaleidoscope/Chapter5/ examples/Kaleidoscope/Chapter6/ examples/Kaleidoscope/Chapter7/ include/llvm/ include/llvm/Support/ lib/Analysis/ lib/AsmParser/ lib/B

[Jay Foad]

On 30 March 2011 13:27, Duncan Sands <baldrick at free.fr> wrote:
> Hi Jay, this makes things more awkward for dragonegg.  When it sees a GCC
> phi node it creates an LLVM phi node.  But it doesn't know how many operands
> the phi node will have.  It does know how many operands the GCC phi node has,
> but if a predecessor basic block has (eg) a switch statement at the end with
> more than one case branching to the phi block then the GCC phi gets one entry
> for the predecessor while the LLVM phi gets more than one.  So dragonegg only
> has a lower bound for the number of phi operands.  It can't just take a look
> in the LLVM predecessors since they probably haven't been output yet.  So
> instead it creates a phi node with no operands, and once all basic blocks have
> been turned into LLVM it revisits each phi node, counts how many operands the
> phi node needs and populates the phi node.
>
> I guess one solution is to delete the empty phi node and create an entirely
> new one.  But maybe you have a better idea?

(Sorry Duncan, forgot to CC the list first time.)

It shouldn't make things more awkward for anyone. If you really don't
have any information about how many operands the phi node will have,
you can create it with 0. This should be exactly equivalent to how
PHINode::Create() method worked before my changes.

The NumReservedValues parameter that I've added to PHINode::Create()
is just a hint, just like the old reserveOperandSpace() method. It
doesn't have to be exactly the right number.

Jay.