SuccessChanges

Summary

  1. [LSR / TTI / SystemZ] Eliminate TargetTransformInfo::isFoldableMemAccess() isLegalAddressingMode() has recently gained the extra optional Instruction* parameter, and therefore it can now do the job that previously only isFoldableMemAccess() could do. The SystemZ implementation of isLegalAddressingMode() has gained the functionality of checking for offsets, which used to be done with isFoldableMemAccess(). The isFoldableMemAccess() hook has been removed everywhere. Review: Quentin Colombet, Ulrich Weigand https://reviews.llvm.org/D35933
  2. [LoopStrengthReduce] Don't neglect the Fixup.Offset in isAMCompletelyFolded(). In the recursive call to isAMCompletelyFolded(), the passed offset should be the sum of F.BaseOffset and Fixup.Offset. Review: Quentin Colombet.
  3. [mips] PR34083 - Wimplicit-fallthrough warning in MipsAsmParser.cpp Assert that a binary expression is actually a binary expression, rather than potientially incorrectly attempting to handle it as a unary expression. This resolves PR34083. Thanks to Simonn Pilgrim for reporting the issue!
  4. Suppress a warning. NFC.
  5. [clang-format] Put '/**' and '*/' on own lines in jsdocs ending in comment pragmas Summary: This handles a case where the trailing '*/' of a multiline jsdoc eding in a comment pragma wouldn't be put on a new line. Reviewers: mprobst Reviewed By: mprobst Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D36359
  6. [AsmParser] Hash is not a comment on some targets The '#' token is not a comment for all targets (on ARM and AArch64 it marks an immediate operand), so we shouldn't treat it as such. Comments are already converted to AsmToken::EndOfStatement by AsmLexer::LexLineComment, so this check was unnecessary. Differential Revision: https://reviews.llvm.org/D36405
  7. [LCG] Completely remove the map-based association of post-order numbers to Nodes when removing ref edges from a RefSCC. This map based association turns out to be pretty expensive for large RefSCCs and pointless as we already have embedded data members inside nodes that we use to track the DFS state. We can reuse one of those and the map becomes unnecessary. This also fuses the update of those numbers into the scan across the pending stack of nodes so that we don't walk the nodes twice during the DFS. With this I expect the new PM to be faster than the old PM for the test case I have been optimizing. That said, it also seems simpler and more direct in many ways. The side storage was always pretty awkward. The last remaining hot-spot in the profile of the LCG once this is done will be the edge iterator walk in the DFS. I'll take a look at improving that next.
  8. [GlobalOpt] Switch an explicit loop to llvm::all_of(). NFCI.
  9. [LCG] Special case when removing a ref edge from a RefSCC leaves that RefSCC still connected. This is common and can be handled much more efficiently. As soon as we know we've covered every node in the RefSCC with the DFS, we can simply reset our state and return. This avoids numerous data structure updates and other complexity. On top of other changes, this appears to get new PM back to parity with the old PM for a large protocol buffer message source code. The dense map updates are very hot in this function.
  10. [LCG] Switch one of the update methods for the LazyCallGraph to support limited batch updates. Specifically, allow removing multiple reference edges starting from a common source node. There are a few constraints that play into supporting this form of batching: 1) The way updates occur during the CGSCC walk, about the most we can functionally batch together are those with a common source node. This also makes the batching simpler to implement, so it seems a worthwhile restriction. 2) The far and away hottest function for large C++ files I measured (generated code for protocol buffers) showed a huge amount of time was spent removing ref edges specifically, so it seems worth focusing there. 3) The algorithm for removing ref edges is very amenable to this restricted batching. There are just both API and implementation special casing for the non-batch case that gets in the way. Once removed, supporting batches is nearly trivial. This does modify the API in an interesting way -- now, we only preserve the target RefSCC when the RefSCC structure is unchanged. In the face of any splits, we create brand new RefSCC objects. However, all of the users were OK with it that I could find. Only the unittest needed interesting updates here. How much does batching these updates help? I instrumented the compiler when run over a very large generated source file for a protocol buffer and found that the majority of updates are intrinsically updating one function at a time. However, nearly 40% of the total ref edges removed are removed as part of a batch of removals greater than one, so these are the cases batching can help with. When compiling the IR for this file with 'opt' and 'O3', this patch reduces the total time by 8-9%. Differential Revision: https://reviews.llvm.org/D36352
  11. [Sema] Extend -Wenum-compare to handle mixed enum comparisons in switch statements Patch by: Reka Nikolett Kovacs Differential Revision: https://reviews.llvm.org/D36407
Revision 310463 by jonpa:
[LSR / TTI / SystemZ]  Eliminate TargetTransformInfo::isFoldableMemAccess()

isLegalAddressingMode() has recently gained the extra optional Instruction*
parameter, and therefore it can now do the job that previously only
isFoldableMemAccess() could do.

The SystemZ implementation of isLegalAddressingMode() has gained the
functionality of checking for offsets, which used to be done with
isFoldableMemAccess().

The isFoldableMemAccess() hook has been removed everywhere.

Review: Quentin Colombet, Ulrich Weigand
https://reviews.llvm.org/D35933
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/include/llvm/Analysis/TargetTransformInfo.hllvm.src/include/llvm/Analysis/TargetTransformInfo.h
The file was modified/llvm/trunk/include/llvm/Analysis/TargetTransformInfoImpl.hllvm.src/include/llvm/Analysis/TargetTransformInfoImpl.h
The file was modified/llvm/trunk/include/llvm/CodeGen/BasicTTIImpl.hllvm.src/include/llvm/CodeGen/BasicTTIImpl.h
The file was modified/llvm/trunk/include/llvm/Target/TargetLowering.hllvm.src/include/llvm/Target/TargetLowering.h
The file was modified/llvm/trunk/lib/Analysis/TargetTransformInfo.cppllvm.src/lib/Analysis/TargetTransformInfo.cpp
The file was modified/llvm/trunk/lib/Target/SystemZ/SystemZISelLowering.cppllvm.src/lib/Target/SystemZ/SystemZISelLowering.cpp
The file was modified/llvm/trunk/lib/Target/SystemZ/SystemZISelLowering.hllvm.src/lib/Target/SystemZ/SystemZISelLowering.h
The file was modified/llvm/trunk/lib/Transforms/Scalar/LoopStrengthReduce.cppllvm.src/lib/Transforms/Scalar/LoopStrengthReduce.cpp
The file was modified/llvm/trunk/test/CodeGen/Hexagon/swp-const-tc.llllvm.src/test/CodeGen/Hexagon/swp-const-tc.ll
Revision 310462 by jonpa:
[LoopStrengthReduce]  Don't neglect the Fixup.Offset in isAMCompletelyFolded().

In the recursive call to isAMCompletelyFolded(), the passed offset should be
the sum of F.BaseOffset and Fixup.Offset.

Review: Quentin Colombet.
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Transforms/Scalar/LoopStrengthReduce.cppllvm.src/lib/Transforms/Scalar/LoopStrengthReduce.cpp
Revision 310460 by sdardis:
[mips] PR34083 - Wimplicit-fallthrough warning in MipsAsmParser.cpp

Assert that a binary expression is actually a binary expression,
rather than potientially incorrectly attempting to handle it as a
unary expression.

This resolves PR34083.

Thanks to Simonn Pilgrim for reporting the issue!
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Target/Mips/AsmParser/MipsAsmParser.cppllvm.src/lib/Target/Mips/AsmParser/MipsAsmParser.cpp
Revision 310459 by xazax:
Suppress a warning. NFC.
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Target/AMDGPU/MCTargetDesc/AMDGPUAsmBackend.cppllvm.src/lib/Target/AMDGPU/MCTargetDesc/AMDGPUAsmBackend.cpp
Revision 310458 by krasimir:
[clang-format] Put '/**' and '*/' on own lines in jsdocs ending in comment pragmas

Summary:
This handles a case where the trailing '*/' of a multiline jsdoc eding in a
comment pragma wouldn't be put on a new line.

Reviewers: mprobst

Reviewed By: mprobst

Subscribers: cfe-commits, klimek

Differential Revision: https://reviews.llvm.org/D36359
Change TypePath in RepositoryPath in Workspace
The file was modified/cfe/trunk/lib/Format/BreakableToken.cppclang.src/lib/Format/BreakableToken.cpp
The file was modified/cfe/trunk/lib/Format/BreakableToken.hclang.src/lib/Format/BreakableToken.h
The file was modified/cfe/trunk/lib/Format/ContinuationIndenter.cppclang.src/lib/Format/ContinuationIndenter.cpp
The file was modified/cfe/trunk/unittests/Format/FormatTestJS.cppclang.src/unittests/Format/FormatTestJS.cpp
Revision 310457 by olista01:
[AsmParser] Hash is not a comment on some targets

The '#' token is not a comment for all targets (on ARM and AArch64 it marks an
immediate operand), so we shouldn't treat it as such.

Comments are already converted to AsmToken::EndOfStatement by
AsmLexer::LexLineComment, so this check was unnecessary.

Differential Revision: https://reviews.llvm.org/D36405
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/MC/MCParser/AsmParser.cppllvm.src/lib/MC/MCParser/AsmParser.cpp
The file was modified/llvm/trunk/lib/MC/MCParser/MCAsmParser.cppllvm.src/lib/MC/MCParser/MCAsmParser.cpp
The file was modified/llvm/trunk/test/DebugInfo/AArch64/asan-stack-vars.llllvm.src/test/DebugInfo/AArch64/asan-stack-vars.ll
The file was modified/llvm/trunk/test/ExecutionEngine/RuntimeDyld/AArch64/ELF_ARM64_relocations.sllvm.src/test/ExecutionEngine/RuntimeDyld/AArch64/ELF_ARM64_relocations.s
The file was modified/llvm/trunk/test/MC/ARM/directive_parsing.sllvm.src/test/MC/ARM/directive_parsing.s
The file was modified/llvm/trunk/test/MC/AsmParser/AArch64/directive-parse-err.sllvm.src/test/MC/AsmParser/AArch64/directive-parse-err.s
Revision 310456 by chandlerc:
[LCG] Completely remove the map-based association of post-order numbers
to Nodes when removing ref edges from a RefSCC.

This map based association turns out to be pretty expensive for large
RefSCCs and pointless as we already have embedded data members inside
nodes that we use to track the DFS state. We can reuse one of those and
the map becomes unnecessary.

This also fuses the update of those numbers into the scan across the
pending stack of nodes so that we don't walk the nodes twice during the
DFS.

With this I expect the new PM to be faster than the old PM for the test
case I have been optimizing. That said, it also seems simpler and more
direct in many ways. The side storage was always pretty awkward.

The last remaining hot-spot in the profile of the LCG once this is done
will be the edge iterator walk in the DFS. I'll take a look at improving
that next.
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Analysis/LazyCallGraph.cppllvm.src/lib/Analysis/LazyCallGraph.cpp
Revision 310453 by davide:
[GlobalOpt] Switch an explicit loop to llvm::all_of(). NFCI.
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Transforms/IPO/GlobalOpt.cppllvm.src/lib/Transforms/IPO/GlobalOpt.cpp
Revision 310451 by chandlerc:
[LCG] Special case when removing a ref edge from a RefSCC leaves
that RefSCC still connected.

This is common and can be handled much more efficiently. As soon as we
know we've covered every node in the RefSCC with the DFS, we can simply
reset our state and return. This avoids numerous data structure updates
and other complexity.

On top of other changes, this appears to get new PM back to parity with
the old PM for a large protocol buffer message source code. The dense
map updates are very hot in this function.
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Analysis/LazyCallGraph.cppllvm.src/lib/Analysis/LazyCallGraph.cpp
Revision 310450 by chandlerc:
[LCG] Switch one of the update methods for the LazyCallGraph to support
limited batch updates.

Specifically, allow removing multiple reference edges starting from
a common source node. There are a few constraints that play into
supporting this form of batching:

1) The way updates occur during the CGSCC walk, about the most we can
   functionally batch together are those with a common source node. This
   also makes the batching simpler to implement, so it seems
   a worthwhile restriction.
2) The far and away hottest function for large C++ files I measured
   (generated code for protocol buffers) showed a huge amount of time
   was spent removing ref edges specifically, so it seems worth focusing
   there.
3) The algorithm for removing ref edges is very amenable to this
   restricted batching. There are just both API and implementation
   special casing for the non-batch case that gets in the way. Once
   removed, supporting batches is nearly trivial.

This does modify the API in an interesting way -- now, we only preserve
the target RefSCC when the RefSCC structure is unchanged. In the face of
any splits, we create brand new RefSCC objects. However, all of the
users were OK with it that I could find. Only the unittest needed
interesting updates here.

How much does batching these updates help? I instrumented the compiler
when run over a very large generated source file for a protocol buffer
and found that the majority of updates are intrinsically updating one
function at a time. However, nearly 40% of the total ref edges removed
are removed as part of a batch of removals greater than one, so these
are the cases batching can help with.

When compiling the IR for this file with 'opt' and 'O3', this patch
reduces the total time by 8-9%.

Differential Revision: https://reviews.llvm.org/D36352
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/include/llvm/Analysis/LazyCallGraph.hllvm.src/include/llvm/Analysis/LazyCallGraph.h
The file was modified/llvm/trunk/lib/Analysis/CGSCCPassManager.cppllvm.src/lib/Analysis/CGSCCPassManager.cpp
The file was modified/llvm/trunk/lib/Analysis/LazyCallGraph.cppllvm.src/lib/Analysis/LazyCallGraph.cpp
The file was modified/llvm/trunk/unittests/Analysis/LazyCallGraphTest.cppllvm.src/unittests/Analysis/LazyCallGraphTest.cpp
Revision 310449 by xazax:
[Sema] Extend -Wenum-compare to handle mixed enum comparisons in switch statements

Patch by: Reka Nikolett Kovacs

Differential Revision: https://reviews.llvm.org/D36407
Change TypePath in RepositoryPath in Workspace
The file was modified/cfe/trunk/lib/Sema/SemaStmt.cppclang.src/lib/Sema/SemaStmt.cpp
The file was modified/cfe/trunk/test/Sema/switch.cclang.src/test/Sema/switch.c
The file was modified/cfe/trunk/test/SemaCXX/warn-enum-compare.cppclang.src/test/SemaCXX/warn-enum-compare.cpp