mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-13 04:30:23 +00:00
41b55f5556
The fundamental problem is that SROA didn't allow for overly wide loads where the bits past the end of the alloca were masked away and the load was sufficiently aligned to ensure there is no risk of page fault, or other trapping behavior. With such widened loads, SROA would delete the load entirely rather than clamping it to the size of the alloca in order to allow mem2reg to fire. This was exposed by a test case that neatly arranged for GVN to run first, widening certain loads, followed by an inline step, and then SROA which miscompiles the code. However, I see no reason why this hasn't been plaguing us in other contexts. It seems deeply broken. Diagnosing all of the above took all of 10 minutes of debugging. The really annoying aspect is that fixing this completely breaks the pass. ;] There was an implicit reliance on the fact that no loads or stores extended past the alloca once we decided to rewrite them in the final stage of SROA. This was used to encode information about whether the loads and stores had been split across multiple partitions of the original alloca. That required threading explicit tracking of whether a *use* of a partition is split across multiple partitions. Once that was done, another problem arose: we allowed splitting of integer loads and stores iff they were loads and stores to the entire alloca. This is a really arbitrary limitation, and splitting at least some integer loads and stores is crucial to maximize promotion opportunities. My first attempt was to start removing the restriction entirely, but currently that does Very Bad Things by causing *many* common alloca patterns to be fully decomposed into i8 operations and lots of or-ing together to produce larger integers on demand. The code bloat is terrifying. That is still the right end-goal, but substantial work must be done to either merge partitions or ensure that small i8 values are eagerly merged in some other pass. Sadly, figuring all this out took essentially all the time and effort here. So the end result is that we allow splitting only when the load or store at least covers the alloca. That ensures widened loads and stores don't hurt SROA, and that we don't rampantly decompose operations more than we have previously. All of this was already fairly well tested, and so I've just updated the tests to cover the wide load behavior. I can add a test that crafts the pass ordering magic which caused the original PR, but that seems really brittle and to provide little benefit. The fundamental problem is that widened loads should Just Work. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177055 91177308-0d34-0410-b5e6-96231b3b80d8 |
||
|---|---|---|
| .. | ||
| ADCE | ||
| ArgumentPromotion | ||
| BBVectorize | ||
| BlockPlacement | ||
| BranchFolding | ||
| CodeExtractor | ||
| CodeGenPrepare | ||
| ConstantMerge | ||
| ConstProp | ||
| CorrelatedValuePropagation | ||
| DeadArgElim | ||
| DeadStoreElimination | ||
| EarlyCSE | ||
| FunctionAttrs | ||
| GCOVProfiling | ||
| GlobalDCE | ||
| GlobalOpt | ||
| GVN | ||
| IndVarSimplify | ||
| Inline | ||
| InstCombine | ||
| InstSimplify | ||
| Internalize | ||
| IPConstantProp | ||
| JumpThreading | ||
| LCSSA | ||
| LICM | ||
| LoopDeletion | ||
| LoopIdiom | ||
| LoopRotate | ||
| LoopSimplify | ||
| LoopStrengthReduce | ||
| LoopUnroll | ||
| LoopUnswitch | ||
| LoopVectorize | ||
| LowerAtomic | ||
| LowerExpectIntrinsic | ||
| LowerInvoke | ||
| LowerSwitch | ||
| Mem2Reg | ||
| MemCpyOpt | ||
| MergeFunc | ||
| MetaRenamer | ||
| ObjCARC | ||
| PhaseOrdering | ||
| PruneEH | ||
| Reassociate | ||
| Reg2Mem | ||
| ScalarRepl | ||
| SCCP | ||
| SimplifyCFG | ||
| SimplifyLibCalls | ||
| Sink | ||
| SROA | ||
| StripSymbols | ||
| TailCallElim | ||
| TailDup | ||