BitcodeReader: Change mechanics of BlockAddress forward references, NFC
authorDuncan P. N. Exon Smith <dexonsmith@apple.com>
Fri, 1 Aug 2014 21:51:52 +0000 (21:51 +0000)
committerDuncan P. N. Exon Smith <dexonsmith@apple.com>
Fri, 1 Aug 2014 21:51:52 +0000 (21:51 +0000)
commit147851ef9d11173c012217511be257ebefe695c4
tree38e6407add820d37ce95f82f14e1d553279d49c9
parent7e595450fb57b093615972e3613861444692bffe
BitcodeReader: Change mechanics of BlockAddress forward references, NFC

Now that we can reliably handle forward references to `BlockAddress`
(r214563), change the mechanics to simplify predicting use-list order.

Previously, we created dummy `GlobalVariable`s to represent block
addresses.  After every function was materialized, we'd go through any
forward references to its blocks and RAUW them with a proper
`BlockAddress` constant.  This causes some (potentially a lot of)
unnecessary use-list churn, since any constant expression that it's a
part of will need to be rematerialized as well.

Instead, pre-construct a `BasicBlock` immediately -- without attaching
it to its (empty) `Function` -- and use that to construct a
`BlockAddress`.  This constant will not have to be regenerated.  When
the function body is parsed, hook this pre-constructed basic block up
in the right place using `BasicBlock::insertInto()`.

Both before and after this change, the IR is temporarily in an invalid
state that gets resolved when `materializeForwardReferencedFunctions()`
gets called.

This is a prep commit that's part of PR5680, but the only functionality
change is the reduction of churn in the constant pool.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214570 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Bitcode/Reader/BitcodeReader.cpp
lib/Bitcode/Reader/BitcodeReader.h