[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/Bitcode/Reader/ lib/CodeGen/ lib/Target/CppBackend/ lib/Transforms/IPO/ lib/Transforms/InstCombine/ lib/Transforms/Instrumentation/ lib/Transforms/Scalar/ lib/Transforms/Utils/ lib/VMCore/ tools/bugpoint/ unittests/Transforms/Utils/

[Duncan Sands]

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?

Ciao, Duncan.