Most of filesystem/path.cpp uses string_view_t. This fixes the two spots
that use string_view directly.
https://reviews.llvm.org/D34332
llvm-svn: 305661
This test makes sure we can handle both arg0 and arg1 handling in the
same binary, and making sure that the XRay runtime calls the correct
trampoline when handlers for both of these cases are installed.
llvm-svn: 305660
Merge the functionality into the random access type collection.
This class was only being used in 2 places, so getting rid of it
simplifies the code.
llvm-svn: 305653
Fix an off-by-one in r302172, which triggered building local versions of
the iostreams when deploying to `<= macOS 10.9`, when it should have
been `< macOS 10.9`. 10.9 had the dylib support.
This defines `_LIBCPP_AVAILABILITY_NO_STREAMS_EXTERN_TEMPLATE` less
often, reducing code size for users with deployment targets of exactly
macOS 10.9 or iOS 7.0.
rdar://problem/32233981
llvm-svn: 305649
Summary:
This allows strlen to be moved out of the loop in case its argument is
not modified in the loop in LICM.
Reviewers: hfinkel, davide, sanjoy, dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34323
llvm-svn: 305641
Fix the type for a (runtime) library call to match both the comment and
the runtime implementation. As it happens, the type being used matched,
this just makes it more precise.
llvm-svn: 305638
No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined.
If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank,
llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE.
Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target.
Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run;
TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/
TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools
Differential Revision: https://reviews.llvm.org/D33662
llvm-svn: 305632
Re-apply r276044/r279124/r305516. Fixed a problem where we would refuse
to place spills as the very first instruciton of a basic block and thus
artifically increase pressure (test in
test/CodeGen/PowerPC/scavenging.mir:spill_at_begin)
This is a variant of scavengeRegister() that works for
enterBasicBlockEnd()/backward(). The benefit of the backward mode is
that it is not affected by incomplete kill flags.
This patch also changes
PrologEpilogInserter::doScavengeFrameVirtualRegs() to use the register
scavenger in backwards mode.
Differential Revision: http://reviews.llvm.org/D21885
llvm-svn: 305625
Summary:
This is my misunderstanding on isBarrier. It's not for memory barriers,
but for other control flow purposes. lwsync doesn't have it either.
This fixes a simple crash with -verify-machineinstrs like below:
define void @Foo() {
entry:
%tmp = load atomic i64, i64* undef acquire, align 8
unreachable
}
I deliberately don't want to check in the test, since there is little
chance to regress on such a mistake. Such a test adds noise to the code
base.
I plan to check in first, since it fixes a crash, and the fix is obvious.
Reviewers: kbarton, echristo
Subscribers: sanjoy, nemanjai, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D34314
llvm-svn: 305624
Summary:
setMustBuildLookupTable should be called on imported TagDecls otherwise we may fail
to import their member decls (if they have any).
Not calling the setMustBuildLookupTable method results in a failure in the attached test
case when lookup for the 'x' member fails on struct S, which hasn't had its decls imported
elsewhere. (By contrast the member-in-struct testcase hasn't run into this issue
because the import of its decls is triggered when the struct instance is defined, and the
member access follows this).
Reviewers: spyffe, rsmith
Reviewed By: spyffe, rsmith
Differential Revision: https://reviews.llvm.org/D34253
llvm-svn: 305619
This ensures that symbolic relocations are generated for stack
pointer manipulations.
These relocations are of type R_WEBASSEMBLY_GLOBAL_INDEX_LEB.
This change also adds support for reading relocations of this
type in WasmObjectFile.cpp.
Since its a globally imported symbol this does mean that
the get_global/set_global instruction won't be valid until
the objects are linked that global used in no longer an
imported global.
Differential Revision: https://reviews.llvm.org/D34172
llvm-svn: 305616
Suppose we had a type index offsets array with a boundary at type index
N. Then you request the name of the type with index N+1, and that name
requires the name of index N-1 (think a parameter list, for example). We
didn't handle this, and we would print something like (<unknown UDT>,
<unknown UDT>).
The fix for this is not entirely trivial, and speaks to a larger
problem. I think we need to kill TypeDatabase, or at the very least kill
TypeDatabaseVisitor. We need a thing that doesn't do any caching
whatsoever, just given a type index it can compute the type name "the
slow way". The reason for the bug is that we don't have anything like
that. Everything goes through the type database, and if we've visited a
record, then we're "done". It doesn't know how to do the expensive thing
of re-visiting dependent records if they've not yet been visited.
What I've done here is more or less copied the code (albeit greatly
simplified) from TypeDatabaseVisitor, but wrapped it in an interface
that just returns a std::string. The logic of caching the name is now in
LazyRandomTypeCollection. Eventually I'd like to move the record
database here as well and the visited record bitfield here as well, at
which point we can actually just delete TypeDatabase. I don't see any
reason for it if a "sequential" collection is just a special case of a
random access collection with an empty partial offsets array.
Differential Revision: https://reviews.llvm.org/D34297
llvm-svn: 305612
David Blaikie