We can't put the unittest source dir map in the configuration
specific directory because VS doesn't have a configure-specific
directory, instead it only knows this at runtime. So we have
to remove this from the path. This in turn means that the path
will be slightly different in VS configurations vs non vs
configurations. In the former, the source map will be in the
parent directory of the executable, and in the latter it will
be in the same directory as the executable. So check both.
llvm-svn: 341590
This patch adds per-function size information remarks. Previously, passing
-Rpass-analysis=size-info would only give you per-module changes. By adding
the ability to do this per-function, it's easier to see which functions
contributed the most to size changes.
https://reviews.llvm.org/D51467
llvm-svn: 341588
It caused ambiguity between llvm:🆑:Optional and llvm::Optional, which
has been fixed by dropping `using namespace cl;` in favor of explicit
cl:: qualified names.
llvm-svn: 341586
Summary:
r338767 updated the COFF and wasm linker SymbolTable code to be
strutured more like the ELF linker's. That inadvertedly changed the
behavior of the COFF linker so that lazy symbols would be marked as
used in regular objects. This change adds an overload of the insert()
function, similar to the ELF linker, which does not perform that
marking.
Reviewers: ruiu, rnk, hans
Subscribers: aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51720
llvm-svn: 341585
`using namespace cl` makes llvm:🆑:Optional (in Support/CommandLine.h) visible which will cause ambiguity when unqualified `Optional` is looked up (can also refer to llvm::Optional).
cl:: is used much more than `using namespace cl`, so let's not use the latter.
Also append \n to the argument of cl::ParseCommandLineOptions
llvm-svn: 341584
Summary:
Instruction printer shouldn't crash with assertions due to incorrect input data. llvm_unreachable is not intended for runtime error handling.
Reviewers: petecoup
Reviewed By: petecoup
Differential Revision: https://reviews.llvm.org/D51728
llvm-svn: 341581
libLLVMTestingSupport.so references a symbol in utils/unittest/UnitTestMain/TestMain.cpp (a layering issue) and will cause a link error because of -Wl,-z,defs (cmake/modules/HandleLLVMOptions.cmake)
Waiting zturner for a better fix.
llvm-svn: 341580
The existing memory manager API can not be shared between objects when linking
concurrently (since there is no way to know which concurrent allocations were
performed on behalf of which object, and hence which allocations would be safe
to finalize when finalizeMemory is called). For now, we can work around this by
requiring a new memory manager for each object.
This change only affects the concurrent version of the ORC APIs.
llvm-svn: 341579
Section address mappings can be applied using the RuntimeDyld instance passed to
the RuntimeDyld::MemoryManager::notifyObjectLoaded method. Proving an alternate
route via RuntimeDyldObjectLinkingLayer2 is redundant.
llvm-svn: 341578
MRI scripts have two comment chars, * and ;, but only the latter was
supported before.
Also allow leading spaces before comment chars (and before any command
string), and allow comments after a command.
Differential Revision: https://reviews.llvm.org/D51338
llvm-svn: 341571
context.
If the explicit template instantiation definition defined outside of the
target context, its vtable should not be marked as used. This is true
for other situations where the compiler want to emit vtables
unconditionally.
llvm-svn: 341570
Keeping the compile units in memory is expensive. For the single
threaded case we allocate them in the analyze part and deallocate them
again once we've finished cloning. This poses a problem in the single
threaded case where we did all the analysis first followed by all the
cloning. This meant we had all the link context in memory right after
analyzing finished.
This patch changes the way we order work in the single threaded case.
Instead of doing all the analysis and cloning in serial, we now
interleave the two so we can deallocate the memory as soon as a file is
processed. The result is binary identical and peak memory usage went
down from 13.43GB to 5.73GB for a debug build of trunk clang.
Differential revision: https://reviews.llvm.org/D51618
llvm-svn: 341568
Namely, print the likely macro name when it's used, and include the actual
computed sizes in the diagnostic message, which are sometimes not obvious.
rdar://43909200
Differential revision: https://reviews.llvm.org/D51697
llvm-svn: 341566
This recommits r341472, which was reverted due to test failures on macos bots.
The issue was that a macos target implies -glldb which, together with
this patch added a -gpubnames switch where there previously wasn't one.
The intentions of those checks was to check that -gpubnames is not
emitted by default so I add an explicit -ggdb arg to those command lines
to get same behavior on all platforms (the fact that -glldb *does* set
-gpubnames is tested by a separate test).
Differential Revision: https://reviews.llvm.org/D51576
llvm-svn: 341564
This fold is needed to avoid a regression when we try
to recommit rL300977.
We can't see the most basic win currently because
demanded bits changes the patterns:
https://rise4fun.com/Alive/plpp
llvm-svn: 341559
Summary:
I added a few ARM64 memset codegen tests in r341406 and r341493, and annotated
where the generated code was bad. This patch fixes the majority of the issues by
requesting that a 2xi64 vector be used for memset of 32 bytes and above.
The patch leaves the former request for f128 unchanged, despite f128
materialization being suboptimal: doing otherwise runs into other asserts in
isel and makes this patch too broad.
This patch hides the issue that was present in bzero_40_stack and bzero_72_stack
because the code now generates in a better order which doesn't have the store
offset issue. I'm not aware of that issue appearing elsewhere at the moment.
<rdar://problem/44157755>
Reviewers: t.p.northover, MatzeB, javed.absar
Subscribers: eraman, kristof.beyls, chrib, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D51706
llvm-svn: 341558
Add the __msan_va_arg_origin_tls TLS array to keep the origins for variadic function parameters.
Change the instrumentation pass to store parameter origins in this array.
This is a reland of r341528.
test/msan/vararg.cc doesn't work on Mips, PPC and AArch64 (because this
patch doesn't touch them), XFAIL these arches.
Also turned out Clang crashed on i80 vararg arguments because of
incorrect origin type returned by getOriginPtrForVAArgument() - fixed it
and added a test.
llvm-svn: 341554
This patch sets URI schemes of Dex to SymbolCollector's default schemes
in case callers tried to pass empty list of schemes. This was the case
for initialization in Clangd main and was a reason of incorrect
behavior.
Also, it fixes a bug with missed `continue;` after spotting invalid URI
scheme conversion.
llvm-svn: 341552
This reverts commit r341519, which generates debug info that causes
backend crashes. (with -split-dwarf-file)
Details in https://reviews.llvm.org/D50495
llvm-svn: 341549
Standardise on check lines:
* CHECK-ASM
* CHECK-OBJ
* CHECK-ASM-AND-OBJ
This allows for the addition of tests involving symbol operands, which will
not result in identical instructions in both assembly and disassembled object
output.
This commit doesn't exploit this reworking to increase test coverage of symbol
operands - that will come in a future patch.
llvm-svn: 341546
I'm preparing to add the same functionality both here and to the DAG
version of this code in D51696 / D51433, so try to make those cases
as similar as possible to avoid bugs.
llvm-svn: 341545
Quality.cpp defines a structure for convenient storage of Top N items,
it should be used instead of the `std::priority_queue` with slightly
obscure semantics.
This patch does not affect functionality.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D51676
llvm-svn: 341544
This patch introduces `PathURI` Search Token kind and utilizes it to
uprank symbols which are defined in files with small distance to the
directory where the fuzzy find request is coming from (e.g. files user
is editing).
Reviewed By: ioeric
Reviewers: ioeric, sammccall
Differential Revision: https://reviews.llvm.org/D51481
llvm-svn: 341542
Zachary Turner