Hal Finkel 48f7a2389e Update IR when merging slots in stack coloring ... The way that stack coloring updated MMOs when merging stack slots, while correct, is suboptimal, and is incompatible with the use of AA during instruction scheduling. The solution, which involves the use of const_cast (and more importantly, updating the IR from within an MI-level pass), obviously requires some explanation: When the stack coloring pass was originally committed, the code in ScheduleDAGInstrs::buildSchedGraph tracked possible alias sets by using GetUnderlyingObject, and all load/store and store/store memory control dependencies where added between SUs at the object level (where only one object, that returned by GetUnderlyingObject, was used to identify the object associated with each MMO). When stack coloring merged stack slots, it would replace MMOs derived from the remapped alloca with the alloca with which the remapped alloca was being replaced. Because ScheduleDAGInstrs only used single objects, and tracked alias sets at the object level, this was a fine solution. In r169744, (Andy and) I updated the code in ScheduleDAGInstrs to use GetUnderlyingObjects, and track alias sets using, potentially, multiple underlying objects for each MMO. This was done, primarily, to provide the ability to look through PHIs, and provide better scheduling for induction-variable-dependent loads and stores inside loops. At this point, the MMO-updating code in stack coloring became suboptimal, because it would clear the MMOs for (i.e. completely pessimize) all instructions for which r169744 might help in scheduling. Updating the IR directly is the simplest fix for this (and the one with, by far, the least compile-time impact), but others are possible (we could give each MMO a small vector of potential values, or make use of a remapping table, constructed from MFI, inside ScheduleDAGInstrs). Unfortunately, replacing all MMO values derived from the remapped alloca with the base replacement alloca fundamentally breaks our ability to use AA during instruction scheduling (which is critical to performance on some targets). The reason is that the original MMO might have had an offset (either constant or dynamic) from the base remapped alloca, and that offset is not present in the updated MMO. One possible way around this would be to use GetPointerBaseWithConstantOffset, and update not only the MMO's value, but also its offset based on the original offset. Unfortunately, this solution would only handle constant offsets, and for safety (because AA is not completely restricted to deducing relationships with constant offsets), we would need to clear all MMOs without constant offsets over the entire function. This would be an even worse pessimization than the current single-object restriction. Any other solution would involve passing around a vector of remapped allocas, and teaching AA to use it, introducing additional complexity and overhead into AA. Instead, when remapping an alloca, we replace all IR uses of that alloca as well (optionally inserting a bitcast as necessary). This is even more efficient that the old MMO-updating code in the stack coloring pass (because it removes the need to call GetUnderlyingObject on all MMO values), removes the single-object pessimization in the default configuration, and enables the correct use of AA during instruction scheduling (all without any additional overhead). LLVM now no longer miscompiles itself on x86_64 when using -enable-misched -enable-aa-sched-mi -misched-bottomup=0 -misched-topdown=0 -misched=shuffle! Fixed PR18497. Because the alloca replacement is now done at the IR level, unless the MMO directly refers to the remapped alloca, the change cannot be seen at the MI level. As a result, there is no good way to fix test/CodeGen/X86/pr14090.ll. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199658 91177308-0d34-0410-b5e6-96231b3b80d8		2014-01-20 14:03:16 +00:00
..
Analysis	BasicAA: We need to check both access sizes when comparing a gep and an	2014-01-16 04:53:18 +00:00
Assembler	Add an inalloca flag to allocas	2014-01-17 23:58:17 +00:00
Bindings
Bitcode	Report a warning when dropping outdated debug info metadata.	2014-01-16 01:51:12 +00:00
BugPoint
CodeGen	Update IR when merging slots in stack coloring	2014-01-20 14:03:16 +00:00
DebugInfo	llvm-symbolizer: make mangled name heuristic apply to all symbols	2014-01-16 17:25:12 +00:00
ExecutionEngine	Revert 199262 - MCJIT remote still failing on ARM	2014-01-15 09:09:46 +00:00
Feature
FileCheck
Instrumentation	[asan] extend asan-coverage (still experimental).	2014-01-17 11:00:30 +00:00
Integer
JitListener
Linker	Debug info (LTO): Move the creation of accessibility flags to	2014-01-18 02:12:00 +00:00
LTO
MC	[x86] Fix disassembly of MOV16ao16 et al.	2014-01-20 12:02:53 +00:00
Object	Fix typo: : not ;	2014-01-16 07:08:22 +00:00
Other	[PM] Wire up the Verifier for the new pass manager and connect it to the	2014-01-20 11:34:08 +00:00
TableGen
tools	llvm-objdump/COFF: Print ordinal base number.	2014-01-17 22:02:24 +00:00
Transforms	Fix all the remaining lost-fast-math-flags bugs I've been able to find. The most important of these are cases in the generic logic for combining BinaryOperators.	2014-01-20 07:44:53 +00:00
Unit
Verifier	[PM] Make the verifier work independently of any pass manager.	2014-01-19 02:22:18 +00:00
YAMLParser
.clang-format
CMakeLists.txt	[CMake] Add llvm-tblgen to dependencies of check-llvm.	2014-01-18 19:01:08 +00:00
lit.cfg
lit.site.cfg.in
Makefile
Makefile.tests
TestRunner.sh