diff options
| author | Michael Kruse <llvm@meinersbur.de> | 2017-09-21 14:23:11 +0000 |
|---|---|---|
| committer | Michael Kruse <llvm@meinersbur.de> | 2017-09-21 14:23:11 +0000 |
| commit | 6d7a7896ce95a1cf3e1408bbbfe6199e965fa419 (patch) | |
| tree | 8c38c8830484c7ca97e3b0c4af9126e81c02eeae /lldb/packages/Python/lldbsuite/test/expression_command/call-function/main.cpp | |
| parent | 0dce2ea75873f3a1ab6e0a42561b63887231be41 (diff) | |
| download | bcm5719-llvm-6d7a7896ce95a1cf3e1408bbbfe6199e965fa419.tar.gz bcm5719-llvm-6d7a7896ce95a1cf3e1408bbbfe6199e965fa419.zip | |
[ScopInfo] Use map for value def/PHI read accesses.
Before this patch, ScopInfo::getValueDef(SAI) used
getStmtFor(Instruction*) to find the MemoryAccess that writes a
MemoryKind::Value. In cases where the value is synthesizable within the
statement that defines, the instruction is not added to the statement's
instruction list, which means getStmtFor() won't return anything.
If the synthesiable instruction is not synthesiable in a different
statement (due to being defined in a loop that and ScalarEvolution
cannot derive its escape value), we still need a MemoryKind::Value
and a write to it that makes it available in the other statements.
Introduce a separate map for this purpose.
This fixes MultiSource/Benchmarks/MallocBench/cfrac where
-polly-simplify could not find the writing MemoryAccess for a use. The
write was not marked as required and consequently was removed.
Because this could in principle happen as well for PHI scalars,
add such a map for PHI reads as well.
llvm-svn: 313881
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/call-function/main.cpp')
0 files changed, 0 insertions, 0 deletions
