Duncan P. N. Exon Smith 147851ef9d 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		2014-08-01 21:51:52 +00:00
..
Reader	BitcodeReader: Change mechanics of BlockAddress forward references, NFC	2014-08-01 21:51:52 +00:00
Writer	UseListOrder: Handle self-users	2014-07-31 18:33:12 +00:00
CMakeLists.txt
LLVMBuild.txt
Makefile
module.modulemap	[modules] Add module maps for LLVM. These are not quite ready for prime-time	2014-05-21 02:46:14 +00:00