Keno Fischer 4db92211d7 [ExecutionDepsFix] Improve clearance calculation for loops ... Summary: In revision rL278321, ExecutionDepsFix learned how to pick a better register for undef register reads, e.g. for instructions such as `vcvtsi2sdq`. While this revision improved performance on a good number of our benchmarks, it unfortunately also caused significant regressions (up to 3x) on others. This regression turned out to be caused by loops such as: PH -> A -> B (xmm<Undef> -> xmm<Def>) -> C -> D -> EXIT ^ | +----------------------------------+ In the previous version of the clearance calculation, we would visit the blocks in order, remembering for each whether there were any incoming backedges from blocks that we hadn't processed yet and if so queuing up the block to be re-processed. However, for loop structures such as the above, this is clearly insufficient, since the block B does not have any unknown backedges, so we do not see the false dependency from the previous interation's Def of xmm registers in B. To fix this, we need to consider all blocks that are part of the loop and reprocess them one the correct clearance values are known. As an optimization, we also want to avoid reprocessing any later blocks that are not part of the loop. In summary, the iteration order is as follows: Before: PH A B C D A' Corrected (Naive): PH A B C D A' B' C' D' Corrected (w/ optimization): PH A B C A' B' C' D To facilitate this optimization we introduce two new counters for each basic block. The first counts how many of it's predecssors have completed primary processing. The second counts how many of its predecessors have completed all processing (we will call such a block *done*. Now, the criteria to reprocess a block is as follows: - All Predecessors have completed primary processing - For x the number of predecessors that have completed primary processing *at the time of primary processing of this block*, the number of predecessors that are done has reached x. The intuition behind this criterion is as follows: We need to perform primary processing on all predecessors in order to find out any direct defs in those predecessors. When predecessors are done, we also know that we have information about indirect defs (e.g. in block B though that were inherited through B->C->A->B). However, we can't wait for all predecessors to be done, since that would cause cyclic dependencies. However, it is guaranteed that all those predecessors that are prior to us in reverse postorder will be done before us. Since we iterate of the basic blocks in reverse postorder, the number x above, is precisely the count of the number of predecessors prior to us in reverse postorder. Reviewers: myatsina Differential Revision: https://reviews.llvm.org/D28759 llvm-svn: 293571		2017-01-30 23:37:03 +00:00
..
Analysis	AMDGPU: Fix atomic_inc/atomic_dec + ds_swizzle not being divergent	2017-01-30 17:09:47 +00:00
Assembler
Bindings
Bitcode
BugPoint
CodeGen	[ExecutionDepsFix] Improve clearance calculation for loops	2017-01-30 23:37:03 +00:00
DebugInfo
Examples
ExecutionEngine
Feature
FileCheck
Instrumentation
Integer
JitListener
LibDriver
Linker
LTO
MC	Fix line endings.	2017-01-30 22:04:23 +00:00
Object	Change the llvm-obdump(1) behavior with the -macho flag and inappropriate file types.	2017-01-30 20:53:17 +00:00
ObjectYAML
Other
SymbolRewriter
TableGen	TableGen: Fix infinite recursion in RegisterBankEmitter	2017-01-30 15:07:01 +00:00
ThinLTO/X86
tools	[WebAssembly] Add wasm support for llvm-readobj	2017-01-30 23:30:52 +00:00
Transforms	[InstCombine] enable (X <<nsw C1) >>s C2 --> X <<nsw (C1 - C2) for vectors with splat constants	2017-01-30 23:35:52 +00:00
Unit
Verifier
YAMLParser
.clang-format
CMakeLists.txt
lit.cfg
lit.site.cfg.in
TestRunner.sh