Inline `Source::getBufferPointer` into its only remaining caller,
`getBufferOrNone`. No functionality change.
Differential Revision: https://reviews.llvm.org/D89430
This patch teaches BasicBlock::print to construct an instance of
SlotTracker with the containing function.
Without this patch, we dump:
*** IR Dump After LoopInstSimplifyPass ***
; Preheader:
br label %1
; Loop:
<badref>: ; preds = %1, %0
br label %1
Note "<badref>" above. This happens because BasicBlock::print calls:
SlotTracker SlotTable(this->getModule());
Note that this constructor does not add the contents of functions to
the slot table. That is, basic blocks are left unnumbered.
This patch fixes the problem by switching to:
SlotTracker SlotTable(this->getParent());
which does add the contents of the Module and the function,
this->getParent(), to the slot table.
Differential Revision: https://reviews.llvm.org/D89567
getVectorPtrTy is private to VectorBlockGenerator, and all uses query
the address space from the passed-in pointer prior to calling it.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D89745
Nullability annotations are implmented using attributes; previusly
clangd would skip over AttributedTypeLoc since their location
points to the attribute instead of the modified type.
Also add some test cases for this.
Differential Revision: https://reviews.llvm.org/D89579
Replace `SourceManager::getMemoryBufferForFile`, which returned a
dereferenceable `MemoryBuffer*` and had a `bool*Invalid` out parameter,
with `getMemoryBufferForFileOrNone` (returning
`Optional<MemoryBufferRef>`) and `getMemoryBufferForFileOrFake`
(returning `MemoryBufferRef`).
Differential Revision: https://reviews.llvm.org/D89429
In D86000 we added a new sanitizer to the integer group
without adding it to the trapping group. This broke usage of
-fsanitize=integer -fsanitize-trap=integer or -fsanitize=integer
-fsanitize-minimal-runtime.
I think we can reasonably expect any new integer sanitizers to be
compatible with trapping and the minimal runtime, so add them to the
trapping group automatically.
Also add a test to ensure that any future additions of sanitizers
to the integer group will most likely result in test failures which
would lead to updates to the minimal runtime if necessary. For this
particular sanitizer no updates are required because it uses the
existing shift_out_of_bounds callback function.
Differential Revision: https://reviews.llvm.org/D89766
This is to simplify icmp instructions in the form like:
%cmp = icmp eq i32 (i8*, i8*)* bitcast (i32 (i32**, i32**)* @f32 to i32
%(i8*, i8*)), bitcast (i32 (i64**, i64**) @f64 to i32 (i8*, i8*)*)
Here @f32 and @f64 are two functions.
Differential Revision: https://reviews.llvm.org/D87850
In a discussion with Jim last week we came to the realization that often
we get asked about things that might not be documented on the website,
but that have been pretty well explained elsewhere. In those situations
it's often easier to quickly answer the question than searching for that
presentation you gave 3 years ago if you remember at all.
This often results in us having to answer the same questions over and
over again. We could add the questions and their answer to the website,
but that means we (1) have to duplicate the work and (2) now have to
maintain it.
A more efficient solution is to add a page with external resources with
the caveat that they might be outdated. That's exactly the purpose of
this patch.
I've added a few links that came to mind, but I don't want to be the
arbiter of what should and should not be included. I'd hope that over
time the community can crowd-source the best resources.
Differential revision: https://reviews.llvm.org/D89215
Using Register instead of unsigned.
Also added isStack to mirror the other members, and eventually remove
the static testers.
Differential Revision: https://reviews.llvm.org/D89718
When generating the use-list order, also consider value uses that are
operands which are wrapped in metadata; e.g. llvm.dbg.value operands.
This fixes PR36778. The test case is based on the reproducer from that
report.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D53758
Avoid having to instantiate and compile a subset of the dominator tree logic
separately for each node type. More importantly, this allows generic
algorithms to be built on top of dominator trees without writing them as
templates -- such algorithms can now use opaque CfgBlockRef and
CfgInterface instead.
A type-erased implementation of dominator trees could be written in
terms of CfgInterface as well, but doing so would change the current
trade-off: it would slightly reduce code size at the cost of a slight
runtime overhead.
This patch does not change the trade-off, as it only does type-erasure
where basic blocks can be treated in a fully opaque way, i.e. it only
moves methods that don't require iteration over CFG successors and
predecessors.
v5:
- rename generic_{begin,end,children} back without the generic_ prefix
and refer explictly to base class methods in NewGVN, which wants to
mutate the order of dominator tree node children directly
v6:
- style change: iDom -> idom; it's arguable whether this is really
invalid, since it is actually standard camelCase, but clang-tidy
complains about it so... *shrug*
- rename {to,from}Generic -> {wrap,unwrap}Ref
Change-Id: Ib860dc04cf8bb093d8ed00be7def40d662213672
Differential Revision: https://reviews.llvm.org/D83089
Remove getAllVGPR32() interface and update the SGPR spill code to use
a proper method to get the relevant VGPR registers list.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D89806
Add a test demonstrating `getFileRef`'s behaviour, which isn't obvious
from code inspection when it's handling a redirected file.
Differential Revision: https://reviews.llvm.org/D89469
In order to drop the final callers to `SourceManager::getBuffer`, change
`FrontendInputFile` to use `Optional<MemoryBufferRef>`. Also updated
the "unowned" version of `SourceManager::createFileID` to take a
`MemoryBufferRef` (it now calls `MemoryBuffer::getMemBuffer`, which
creates a `MemoryBuffer` that does not own the buffer data).
Differential Revision: https://reviews.llvm.org/D89427
Do not crash when AsanThread::GetStackVariableShadowStart does not find
a variable for a pointer on a shadow stack.
Differential Revision: https://reviews.llvm.org/D89552
It turned out that at dynamic shared library mode, the memory access
pattern can increase memory footprint significantly on OS when transparent
hugepages (THP) are enabled. This could cause >70x memory overhead than
running a static linked binary. For example, a static binary with RSS
overhead 300M can use > 23G RSS if it is built dynamically.
/proc/../smaps shows in 6204552 kB RSS 6141952 kB relates to
AnonHugePages.
Also such a high RSS happens in some rate: around 25% runs may use > 23G RSS, the
rest uses in between 6-23G. I guess this may relate to how user memory
is allocated and distributted across huge pages.
THP is a trade-off between time and space. We have a flag
no_huge_pages_for_shadow for sanitizer. It is true by default but DFSan
did not follow this. Depending on if a target is built statically or
dynamically, maybe Clang can set no_huge_pages_for_shadow accordingly
after this change. But it still seems fine to follow the default setting of
no_huge_pages_for_shadow. If time is an issue, and users are fine with
high RSS, this flag can be set to false selectively.
Use p.string() instead of p.native() for comparing with the expected
value.
Explicitly list the expected values for both posix and windos, even if
the operation is an identity operation on posix.
Differential Revision: https://reviews.llvm.org/D89532
This is defined both by libcxx/utils/libcxx/test/config.py (for
any windows target) and msvc_stdlib_force_include.h (when testing
specifically the MSVC C++ library).
The command line define (-D_CRT_SECURE_NO_WARNINGS) defines it to the
value 1; change the header define to match that.
Keeping both instances, to keep the fix for cases when not building
in cases that don't use config.py.
Also remove a comment about whether this can be removed; it can't at
least be removed altogether - doing that breaks a number of tests that
otherwise succeed.
Differential Revision: https://reviews.llvm.org/D89588
The combination has not been tested before. In the case of ICF,
`e.section->getVA(0)` equals the start address of the output section.
This can cause incorrect overlapping with the actual function at the
start of the output section and potentially trigger a GDB internal error
in `dw2_find_pc_sect_compunit_symtab` (presumably because:
if a short address range incorrectly starts at the start address of the
output section, GDB may pick it instead of the correct longer address
range. When mapping an address within the long address range but
out of the scope of the short address range, the routine may find
nothing - while the code asserts that it can find something).
Note that in the case of ICF there may be duplicate address range entries,
but GDB appears to be fine with them.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D89751
This is a follow up patch of https://reviews.llvm.org/D88755.
When set 0 label for an address range, we can release pages within the
corresponding shadow address range to OS, and set only addresses outside
the pages to be 0.
Reviewed-by: morehouse, eugenis
Differential Revision: https://reviews.llvm.org/D89199
isMemTerminator checks if the current def is a memory terminator that
terminates the memory pointed to by DefLoc. We do not have to add any of
their users to the worklist, because the follow-on users cannot read the
memory in question.
This leads to more stores eliminated in the presence of lifetime calls.
Previously we added the users of those intrinsics to the worklist,
limiting elimination.
In terms of removed stores, this gives a nice boost on some benchmarks
(MultiSource/SPEC2000/SPEC2006 on X86 with -flto -O3):
Same hash: 205 (filtered out)
Remaining: 32
Metric: dse.NumFastStores
Program base patch diff
test-suite...000/197.parser/197.parser.test 4.00 8.00 100.0%
test-suite...rolangs-C++/family/family.test 4.00 7.00 75.0%
test-suite...marks/7zip/7zip-benchmark.test 1722.00 2189.00 27.1%
test-suite...CFP2000/177.mesa/177.mesa.test 30.00 38.00 26.7%
test-suite :: External/Nurbs/nurbs.test 44.00 49.00 11.4%
test-suite...lications/sqlite3/sqlite3.test 115.00 128.00 11.3%
test-suite...006/447.dealII/447.dealII.test 2715.00 3013.00 11.0%
test-suite...ProxyApps-C++/CLAMR/CLAMR.test 237.00 261.00 10.1%
test-suite...tions/lambda-0.1.3/lambda.test 40.00 44.00 10.0%
test-suite...3.xalancbmk/483.xalancbmk.test 1366.00 1475.00 8.0%
test-suite...abench/jpeg/jpeg-6a/cjpeg.test 13.00 14.00 7.7%
test-suite...oxyApps-C++/miniFE/miniFE.test 43.00 46.00 7.0%
test-suite...lications/ClamAV/clamscan.test 230.00 246.00 7.0%
test-suite...006/450.soplex/450.soplex.test 284.00 299.00 5.3%
test-suite...nsumer-jpeg/consumer-jpeg.test 21.00 22.00 4.8%
The patch adjusts the existing `llvm::DenseMap<unsigned, T>` and
`llvm::DenseSet<unsigned>` objects that store source locations, so
that they use `SourceLocation` directly instead of `unsigned`.
This patch relies on the `DenseMapInfo` trait added in D89719.
It also replaces the construction of `SourceLocation` objects from
the constants -1 and -2 with calls to the trait's methods `getEmptyKey`
and `getTombstoneKey` where appropriate.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D69840
To pacify a GCC warning:
[1/1] Building CXX object tools/clang/lib/Analysis/CMakeFiles/obj.clangAnalysis.dir/Dominators.cpp.o
In file included from /work/llvm.monorepo/clang/include/clang/AST/NestedNameSpecifier.h:18:0,
from /work/llvm.monorepo/clang/include/clang/AST/Type.h:21,
from /work/llvm.monorepo/clang/include/clang/AST/DeclarationName.h:16,
from /work/llvm.monorepo/clang/include/clang/AST/DeclBase.h:18,
from /work/llvm.monorepo/clang/include/clang/Analysis/AnalysisDeclContext.h:20,
from /work/llvm.monorepo/clang/include/clang/Analysis/Analyses/Dominators.h:16,
from /work/llvm.monorepo/clang/lib/Analysis/Dominators.cpp:9:
/work/llvm.monorepo/clang/include/clang/Basic/Diagnostic.h:
In copy constructor ‘clang::DiagnosticBuilder::DiagnosticBuilder(const clang::DiagnosticBuilder&)’:
/work/llvm.monorepo/clang/include/clang/Basic/Diagnostic.h:1287:3:
warning: base class ‘class clang::StreamingDiagnostic’ should be explicitly initialized in the copy constructor [-Wextra]
DiagnosticBuilder(const DiagnosticBuilder &D) {
^
In file included from /work/llvm.monorepo/clang/include/clang/AST/Type.h:29:0,
from /work/llvm.monorepo/clang/include/clang/AST/DeclarationName.h:16,
from /work/llvm.monorepo/clang/include/clang/AST/DeclBase.h:18,
from /work/llvm.monorepo/clang/include/clang/Analysis/AnalysisDeclContext.h:20,
from /work/llvm.monorepo/clang/include/clang/Analysis/Analyses/Dominators.h:16,
from /work/llvm.monorepo/clang/lib/Analysis/Dominators.cpp:9:
/work/llvm.monorepo/clang/include/clang/Basic/PartialDiagnostic.h:
In copy constructor ‘clang::PartialDiagnostic::PartialDiagnostic(const clang::PartialDiagnostic&)’:
/work/llvm.monorepo/clang/include/clang/Basic/PartialDiagnostic.h:52:3:
warning: base class ‘class clang::StreamingDiagnostic’ should be explicitly initialized in the copy constructor [-Wextra]
PartialDiagnostic(const PartialDiagnostic &Other) : DiagID(Other.DiagID) {
^
It was failing with:
In file included from /work/llvm.monorepo/clang/lib/Analysis/Dominators.cpp:9:0:
/work/llvm.monorepo/clang/include/clang/Analysis/Analyses/Dominators.h: At global scope:
/work/llvm.monorepo/clang/include/clang/Analysis/Analyses/Dominators.h:111:26:
error: specialization of ‘template<class CfgRelatedTypeT> struct llvm::CfgTraitsFor’ in different namespace [-fpermissive]
template <> struct llvm::CfgTraitsFor<clang::CFGBlock> {
^
In file included from /work/llvm.monorepo/clang/include/clang/Analysis/Analyses/Dominators.h:21:0,
from /work/llvm.monorepo/clang/lib/Analysis/Dominators.cpp:9:
/work/llvm.monorepo/llvm/include/llvm/Support/CfgTraits.h:294:44:
error: from definition of ‘template<class CfgRelatedTypeT> struct llvm::CfgTraitsFor’ [-fpermissive]
template <typename CfgRelatedTypeT> struct CfgTraitsFor;
^
This change creates a `DenseMapInfo` trait specialization for the
SourceLocation class. The empty key, the tombstone key, and the hash
function are identical to `DenseMapInfo<unsigned>`, because we already
have hash maps that use raw the representation of `SourceLocation` as
a key.
The update of existing `DenseMap`s containing raw representation of
`SourceLocation`s will be done in a follow-up patch. As an example
the patch makes use of the new trait in one instance:
clang-tidy/google/UpgradeGoogletestCaseCheck.{h,cpp}
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D89719
Since 9b40ee8eb0, new/delete must be requested explicitly during the
CMake configuration if one wants these definitions to appear in libc++.
Differential Revision: https://reviews.llvm.org/D89793
Craig Topper