summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2018-06-02 01:29:01 +0000
committerChandler Carruth <chandlerc@gmail.com>2018-06-02 01:29:01 +0000
commit9281503e8f7573b09e151c0de89dbcb682b288be (patch)
tree822569f1aa891a3fb68bc6fad1499f5568a70366 /clang/lib/Frontend/CompilerInvocation.cpp
parentdb5781a78ff3309f3f338f72d84bf0c072547ee3 (diff)
downloadbcm5719-llvm-9281503e8f7573b09e151c0de89dbcb682b288be.tar.gz
bcm5719-llvm-9281503e8f7573b09e151c0de89dbcb682b288be.zip
[PM/LoopUnswitch] Fix how the cloned loops are handled when updating analyses.
Summary: I noticed this issue because we didn't put the primary cloned loop into the `NonChildClonedLoops` vector and so never iterated on it. Once I fixed that, it made it clear why I had to do a really complicated and unnecesasry dance when updating the loops to remain in canonical form -- I was unwittingly working around the fact that the primary cloned loop wasn't in the expected list of cloned loops. Doh! Now that we include it in this vector, we don't need to return it and we can consolidate the update logic as we correctly have a single place where it can be handled. I've just added a test for the iteration order aspect as every time I changed the update logic partially or incorrectly here, an existing test failed and caught it so that seems well covered (which is also evidenced by the extensive working around of this missing update). Reviewers: asbirlea, sanjoy Subscribers: mcrosier, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D47647 llvm-svn: 333811
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud