Currently, the availability of DSP instructions (ACLE 6.4.7) is handled in a
hand-rolled tricky condition block in tools/clang/lib/Basic/Targets.cpp, with
a FIXME: attached.
This patch changes the handling of +t2dsp to be in line with other
architecture extensions.
Following a revert of r248152 and new review comments, this patch also includes
renaming FeatureDSPThumb2 -> FeatureDSP, hasThumb2DSP() -> hasDSP(), etc.
The spelling of "t2dsp" is preserved, pending a further investigation of its
possible external usage.
Differential Revision: http://reviews.llvm.org/D12937
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@248519 91177308-0d34-0410-b5e6-96231b3b80d8
Note: I'm am not trying to describe what "should be"; I'm only describing what is true today.
This came out of my recent question to llvm-dev titled: When can the dominator tree not contain a node for a basic block?
Differential Revision: http://reviews.llvm.org/D13078
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@248417 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, the availability of DSP instructions (ACLE 6.4.7) is handled in a
hand-rolled tricky condition block in tools/clang/lib/Basic/Targets.cpp, with
a FIXME: attached.
This patch changes the handling of +t2dsp to be in line with other
architecture extensions.
Following review comments, also updating the description of FeatureDSPThumb2
in ARM.td.
Differential Revision: http://reviews.llvm.org/D12937
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@248152 91177308-0d34-0410-b5e6-96231b3b80d8
This adds enough machinery to support reading simple GCC AutoFDO
profiles. It now supports reading flat profiles (no function calls).
Subsequent patches will add support for:
- Inlined calls (in particular, the inline call stack is not traversed
to accumulate samples).
- Working sets and modules. These are used mostly for GCC's LIPO
optimizations, so they're not needed in LLVM atm. I'm not sure that
we will ever need them. For now, I've if0'd around the calls.
The patch also adds support in GCOV.h for gcov version V704 (generated
by GCC's profile conversion tool).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247874 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change. Thanks go to Pavel Labath for fixing LLDB for me.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247692 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247683 91177308-0d34-0410-b5e6-96231b3b80d8
When the driver tries to locate a program by its name, e.g. a linker, it
scans the paths provided by the toolchain using the ScanDirForExecutable
function. If the lookup fails, the driver uses
llvm::sys::findProgramByName. Unlike llvm::sys::findProgramByName,
ScanDirForExecutable is not aware of file extensions. If the program has
the "exe" extension in its name, which is very common on Windows,
ScanDirForExecutable won't find it under the toolchain-provided paths.
This patch changes the Windows version of the "`can_execute`" function
called by ScanDirForExecutable to respect file extensions, similarly to
llvm::sys::findProgramByName.
Patch by Oleg Ranevskyy
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D12711
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247358 91177308-0d34-0410-b5e6-96231b3b80d8
Except the changes that defined virtual destructors as =default, because that
ran into problems with GCC 4.7 and overriding methods that weren't noexcept.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247298 91177308-0d34-0410-b5e6-96231b3b80d8
'inline' specifier. That specifier may or may not be valid for a given
function, or it may be required for correct linkage even when the
compiler doesn't support the always_inline attribute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247252 91177308-0d34-0410-b5e6-96231b3b80d8
Removed "cortex-r5f" and "cortex-m4f" from Target Parser, sinced they are
unknown cpu names for llvm and clang. Also updated default FPUs for R5 and M4
accordingly.
Differential Revision: http://reviews.llvm.org/D12692
Change-Id: Ib81c7216521a361d8ee1296e4b6a2aa00bd479c5
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247136 91177308-0d34-0410-b5e6-96231b3b80d8
COFF sections are accompanied with an auxiliary symbol which includes a
checksum. This checksum used to be filled with just zero but this seems
to upset LINK.exe when it is processing a /INCREMENTAL link job.
Instead, fill the CheckSum field with the JamCRC of the section
contents. This matches MSVC's behavior.
This fixes PR19666.
N.B. A rather simple implementation of JamCRC is given. It implements
a byte-wise calculation using the method given by Sarwate. There are
implementations with higher throughput like slice-by-eight and making
use of PCLMULQDQ. We can switch to one of those techniques if it turns
out to be a significant use of time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246590 91177308-0d34-0410-b5e6-96231b3b80d8
This was last used by the pre-MC object emitter and has been dead for
quite a while. We have better ways to emit endian-dependent stuff now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246571 91177308-0d34-0410-b5e6-96231b3b80d8
This would have suppressed bug 24578, about use-after-
destroy on User and MDNode. Rolled back suppression for
the sake of code cleanliness, in preferance for bug
tracking to keep track of this issue.
This reverts commit 6ff2baabc4625d5b0a8dccf76aa0f72d930ea6c0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246484 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, the header now provides llvm::thread, which is either a
typedef of std::thread or a replacement that calls the function synchronously
depending on the value of LLVM_ENABLE_THREADS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246402 91177308-0d34-0410-b5e6-96231b3b80d8
of its strings when expanding the string literals from the macros, and
push all of the APIs to be StringRef instead of C-string APIs.
This (remarkably) removes a very non-trivial number of strlen calls. It
even deletes code and complexity from one of the primary users -- Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246374 91177308-0d34-0410-b5e6-96231b3b80d8
the necessary tables.
This will allow me to restructure the code and structures using this to
be significantly more efficient. It also removes the duplication of the
list of several enumerators. It also enshrines that the order of
enumerators match the order of the entries in the tables, something the
implementation code actually uses.
No functionality changed (yet).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246370 91177308-0d34-0410-b5e6-96231b3b80d8
parsing logic prior to making substantial changes to it.
This parsing logic is incredibly wasteful, so I'm planning to rewrite
it. Just unittesting the triple parsing logic spends well over 80% of
its time in the ARM parsing logic, and others have measured significant
time spent here in real production compiles.
Stay tuned...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246369 91177308-0d34-0410-b5e6-96231b3b80d8
This header is a wrapper for <thread> that works around problems with the
MSVC headers when exceptions are disabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246218 91177308-0d34-0410-b5e6-96231b3b80d8
Remove support for Valgrind-based TSan, which hasn't been maintained for a
few years. We now use the TSan annotations only if LLVM is compiled with
-fsanitize=thread. We no longer need the weak function definitions as we
are guaranteed that our program is linked directly with the TSan runtime.
Differential Revision: http://reviews.llvm.org/D12121
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245374 91177308-0d34-0410-b5e6-96231b3b80d8
This patch makes the Darwin ARM backend take advantage of TargetParser. It
also teaches TargetParser about ARMV7K for the first time. This makes target
triple parsing more consistent across llvm.
Differential Revision: http://reviews.llvm.org/D11996
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245081 91177308-0d34-0410-b5e6-96231b3b80d8
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as the stream and its SmallString are always in sync.
Thanks to David Blaikie for reviewing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244928 91177308-0d34-0410-b5e6-96231b3b80d8
This is faster and avoids the stream and SmallString state synchronization issue.
resync() is a no-op and may be safely deleted. I'll do so in a follow-up commit.
Reviewed by Rafael Espindola.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244870 91177308-0d34-0410-b5e6-96231b3b80d8
PrettyStackTraceHead is a LLVM_THREAD_LOCAL, which means it's just a global
in LLVM_ENABLE_THREADS=NO builds. If a CrashRecoveryContext is used with
code that uses PrettyStackEntries, and a crash happens, PrettyStackTraceHead is
currently not reset to its pre-crash value. These functions make it possible
to add a cleanup to such code that does this.
(Not reseting the value then causes the assert in ~PrettyStackTraceEntry() to
fire if the code outside of the CrashRecoveryContext also uses
PrettyStackEntries -- for example, clang when building a module.)
Part of PR11974.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244338 91177308-0d34-0410-b5e6-96231b3b80d8
