This is a workaround for large file writes. It has been witnessed that
write(2) failing with EINVAL (22) due to a large value (>2G). Thanks to
James Knight for the help with coming up with a sane test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305846 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305632 91177308-0d34-0410-b5e6-96231b3b80d8
This patch should fix sanitizer-x86_64-linux-fast bot.
The problem was that the contents of this stream are aligned to 4 byte,
and the paddings were created just by incrementing `Offset`, so paddings
had undefined values. When the entire stream is written to an output,
it triggered msan.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305541 91177308-0d34-0410-b5e6-96231b3b80d8
It doesn't seem relevant to set an address space limit - this isn't
important in any sense that I'm aware & it gets in the way of things
that use a lot of address space, like llvm-symbolizer.
This came up when I realized that bugpoint regression tests were much
slower with -gsplit-dwarf than plain -g. Turned out that bugpoint
subprocesses (opt, etc) were crashing and doing symbolization - but
bugpoint runs those subprocesses with a 400MB memory limit. So with
plain -g, mmaping the opt binary would exceed the memory limit, fail,
and thus be really fast - no symbolization occurred. Whereas with
-gsplit-dwarf, comically, having less to map in, it would succeed and
then spend lots of time symbolizing.
I've fixed at least the critical part of bugpoint's perf problem there
by adding an option to allow bugpoint to disable symbolization. Thus
improving the perfromance for -gsplit-dwarf and making the -g-esque
speed available without this quirk/accidental benefit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305242 91177308-0d34-0410-b5e6-96231b3b80d8
This is a precursor to another change (coming soon) that aims to make
FoldingSet's API more type-safe. Without this, the type-safety change
would just duplicate 4 more public methods between the already very
similar classes.
This renames FoldingSetImpl to FoldingSetBase so it's consistent with
the FooBase -> FooImpl<T> -> Foo<T> convention we seem to have with
other containers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305231 91177308-0d34-0410-b5e6-96231b3b80d8
Initial implementation - needs similar work/testing for other tools
bugpoint invokes (llc, lli I think, maybe more).
Alternatively (as suggested by chandlerc@) an environment variable could
be used. This would allow the option to pass transparently through user
scripts, pass to compilers if they happened to be LLVM-ish, etc.
I worry a bit about using cl::opt in the crash handling code - LLVM
might crash early, perhaps before the cl::opt is properly initialized?
Or at least before arguments have been parsed?
- should be OK since it defaults to "pretty", so if the crash is very
early in opt parsing, etc, then crash reports will still be symbolized.
I shyed away from doing this with an environment variable when I
realized that would require copying the existing environment and
appending the env variable of interest. But it seems there's no existing
LLVM API for accessing the environment (even the Support tests for
process launching have their own ifdefs for getting the environment). It
could be added, but seemed like a higher bar/untested codepath to
actually add environment variables.
Most importantly, this reduces the runtime of test/BugPoint/metadata.ll
in a split-dwarf Debug build from 1m34s to 6.5s by avoiding a lot of
symbolication. (this wasn't a problem for non-split-dwarf builds only
because the executable was too large to map into memory (due to bugpoint
setting a 400MB memory (including address space - not sure why? Going to
remove that) limit on the child process) so symbolication would fail
fast & wouldn't spend all that time parsing DWARF, etc)
Reviewers: chandlerc, dannyb
Differential Revision: https://reviews.llvm.org/D33804
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305056 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch updates Triple::isCompatibleWith to make armxx and thumbxx
triples compatible, as long as the subarch, vendor, os, envorionment and
object format match. Thumb/ARM code generation should be controlled
using the thumb-mode per-function target feature rather than by the
triple to allow mixing Thumb and ARM functions.
D33448 updates Clang's codegen to add thumb-mode for all functions with
armxx or thumbxx triples.
Reviewers: echristo, t.p.northover, rafael, kristof.beyls, rengolin, tejohnson
Reviewed By: tejohnson
Subscribers: rinon, eugenis, pcc, srhines, aemerson, mehdi_amini, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33287
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304884 91177308-0d34-0410-b5e6-96231b3b80d8
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304864 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I would like to add printing of registered targets to clang's version
information. For this to work correctly, the VersionPrinter logic in
CommandLine.cpp should support printing to arbitrary raw_ostreams,
instead of always defaulting to outs().
Add a raw_ostream& parameter to the function pointer type used for
VersionPrinter, and while doing so, introduce a typedef for convenience.
Note that VersionPrinter::print() will still default to using outs(),
the clang part will necessarily go into a separate review.
Reviewers: beanz, chandlerc, dberris, mehdi_amini, zturner
Reviewed By: mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33899
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304835 91177308-0d34-0410-b5e6-96231b3b80d8
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304787 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Wasm object format has some functionality regressions from the ELF format, and doesn't play nicely with the rest of the toolchain. It should eventually be the default, but not yet.
Reviewers: sunfish, sbc100
Subscribers: jfb, dschuff, llvm-commits
Differential Revision: https://reviews.llvm.org/D33811
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304512 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Solaris-specific implementation for llvm::sys::fs::is_local_impl.
FStype pattern matching might be a bit unreliable, but at least it fixes the build failure.
Reviewers: mgorny, nlopes, llvm-commits, krytarowski
Reviewed By: krytarowski
Subscribers: voskresensky.vladimir, krytarowski
Differential Revision: https://reviews.llvm.org/D33695
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304412 91177308-0d34-0410-b5e6-96231b3b80d8
This is super awkward, but GCC doesn't let us have template visible when
an argument is an inline function and -fvisibility-inlines-hidden is
used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304175 91177308-0d34-0410-b5e6-96231b3b80d8
error C2971: 'llvm::ManagedStatic': template parameter 'Creator': 'CreateDefaultTimerGroup': a variable with non-static storage duration cannot be used as a non-type argument
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304157 91177308-0d34-0410-b5e6-96231b3b80d8
This used to be just leaked. r295370 made it use magic statics. This adds
a global destructor, which is something we'd like to avoid. It also creates
a weird situation where the mutex used by TimerGroup is re-created during
global shutdown and leaked.
Using a ManagedStatic here is also subtle as it relies on the mutex
inside of ManagedStatic to be recursive. I've added a test for that
in a previous change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304156 91177308-0d34-0410-b5e6-96231b3b80d8
ConvertUTF.cpp has a little dependency on LLVM, and since the code extensively uses fall-through switches,
I prefer disabling the warning for the whole file, rather than adding attributes for each case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304120 91177308-0d34-0410-b5e6-96231b3b80d8
WebAssemly uses a custom object file format. For the wasm targets,
default to the `Wasm` object file format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304117 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
r295737 included a fix for leaking libraries loaded via. DynamicLibrary::addPermanentLibrary.
This created a problem where static constructors in a library could insert llvm::ManagedStatic objects before DynamicLibrary would register it's own ManagedStatic, meaning a crash could occur at shutdown.
r301562 exasperated this problem by cleaning up the DynamicLibrary ManagedStatic during llvm_shutdown.
Reviewers: v.g.vassilev, lhames, efriedma
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33581
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304027 91177308-0d34-0410-b5e6-96231b3b80d8
Previously it would do a character by character search for a null
terminator, to account for the fact that an arbitrary stream need not
store its data contiguously so you couldn't just do a memchr. However, the
stream API has a function which will return the longest contiguous chunk
without doing a copy, and by using this function we can do a memchr on the
individual chunks. For certain types of streams like data from object
files etc, this is guaranteed to find the null terminator with only a
single memchr, but even with discontiguous streams such as
MappedBlockStream, it's rare that any given string will cross a block
boundary, so even those will almost always be satisfied with a single
memchr.
This optimization is worth a 10-12% reduction in link time (4.2 seconds ->
3.75 seconds)
Differential Revision: https://reviews.llvm.org/D33503
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303918 91177308-0d34-0410-b5e6-96231b3b80d8
AVX512_VPOPCNTDQ is a new feature set that was published by Intel.
The patch represents the LLVM side of the addition of two new intrinsic based instructions (vpopcntd and vpopcntq).
Differential Revision: https://reviews.llvm.org/D33169
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303858 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds udiv/sdiv/urem/srem/udivrem/sdivrem methods that can divide by a uint64_t. This makes division consistent with all the other arithmetic operations.
This modifies the interface of the divide helper method to work on raw arrays instead of APInts. This way we can pass the uint64_t in for the RHS without wrapping it in an APInt. This required moving all the Quotient and Remainder allocation handling up to the callers. For udiv/urem this was as simple as just creating the Quotient/Remainder with the right size when they were declared. For udivrem we have to rely on reallocate not changing the contents of the variable LHS or RHS is aliased with the Quotient or Remainder APInts. We also have to zero the upper bits of Remainder and Quotient that divide doesn't write to if lhsWords/rhsWords is smaller than the width.
I've update the toString method to use the new udivrem.
Reviewers: hans, dblaikie, RKSimon
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33310
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303431 91177308-0d34-0410-b5e6-96231b3b80d8
compatible target triple
Currently, an assertion fails in ThinLTOCodeGenerator::addModule when
the target triple of the module being added doesn't match that of the
one stored in TMBuilder. This patch relaxes the constraint and makes
changes to allow target triples that only differ in their version
numbers on Apple platforms, similarly to what r228999 did.
rdar://problem/30133904
Differential Revision: https://reviews.llvm.org/D33291
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303326 91177308-0d34-0410-b5e6-96231b3b80d8
Often you have an array and you just want to use it. With the current
design, you have to first construct a `BinaryByteStream`, and then create
a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer
to the `BinaryByteStream`, so you can't just create a temporary one to
appease the compiler, you have to actually hold onto both the `ArrayRef`
as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of
that. This makes for very cumbersome code, often requiring one to store a
`BinaryByteStream` in a class just to circumvent this.
At the cost of some added complexity (not exposed to users, but internal
to the library), we can do better than this. This patch allows us to
construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from
source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only
does this reduce the amount of code you have to type and make it more
obvious how to use it, but it solves real lifetime issues when it's
inconvenient to hold onto a `BinaryByteStream` for a long time.
The additional complexity is in the form of an added layer of indirection.
Whereas before we simply stored a `BinaryStream*` in the ref, we now store
both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When
the user wants to construct a `BinaryStreamRef` directly from an
`ArrayRef` etc, we allocate an internal object that holds ownership over a
`BinaryByteStream` and forwards all calls, and store this in the
`shared_ptr<>`. This also maintains the ref semantics, as you can copy it
by value and references refer to the same underlying stream -- the one
being held in the object stored in the `shared_ptr`.
Differential Revision: https://reviews.llvm.org/D33293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303294 91177308-0d34-0410-b5e6-96231b3b80d8
driver-mode recognition in clang (this is because the sysctl method
always returns one and only one executable path, even for an executable
with multiple links):
Fix DynamicLibraryTest.cpp on FreeBSD and NetBSD
Summary:
After rL301562, on FreeBSD the DynamicLibrary unittests fail, because
the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since
the path does not contain any slashes, retrieving the main executable
will not work.
Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3),
which is more reliable than fiddling with relative or absolute paths.
Also add retrieval of the original argv[] from the GoogleTest framework,
to use as a fallback for other OSes.
Reviewers: emaste, marsupial, hans, krytarowski
Reviewed By: krytarowski
Subscribers: krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D33171
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303285 91177308-0d34-0410-b5e6-96231b3b80d8
We have to check gCrashRecoveryEnabled before using __try.
In other words, SEH works too well and we ended up recovering from
crashes in implicit module builds that we weren't supposed to. Only
libclang is supposed to enable CrashRecoveryContext to allow implicit
module builds to crash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303279 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It avoids problems when other libraries raise exceptions. In particular,
OutputDebugString raises an exception that the debugger is supposed to
catch and suppress. VEH kicks in first right now, and that is entirely
incorrect.
Unfortunately, GCC does not support SEH, so I've kept the old buggy VEH
codepath around. We could fix it with SetUnhandledExceptionFilter, but
that is not per-thread, so a well-behaved library shouldn't set it.
Reviewers: zturner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33261
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303274 91177308-0d34-0410-b5e6-96231b3b80d8
