------------------------------------------------------------------------
r227574 | geek4civic | 2015-01-30 08:01:19 -0500 (Fri, 30 Jan 2015) | 2 lines
[Cygming] Seek also chkstk_ms, or JIT fails with DLL builds. It is fixup for r227519.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@236379 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r228507 | joerg | 2015-02-07 13:24:06 -0800 (Sat, 07 Feb 2015) | 4 lines
Avoid integer overflows around realloc calls resulting in potential
heap. Problem identified by Guido Vranken. Changes differ from original
OpenBSD sources by not depending on non-portable reallocarray.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228511 91177308-0d34-0410-b5e6-96231b3b80d8
and ThreadLocal out of the pretty stack tracing code."
The patch has been having trouble on trunk and doesn't seem ready for 3.6.
Reverting to get it out of the branch before tagging rc2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227646 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227085 | joerg | 2015-01-26 03:41:48 -0800 (Mon, 26 Jan 2015) | 13 lines
The canonical CPU variant for ARM according to config.guess uses a
suffix it seems:
# ./config.guess
earmv7hfeb-unknown-netbsd7.99.4
Extend the triple parsing to support this. Avoid running the ARM parser
multiple times because StringSwitch is not lazy.
Reviewers: Renato Golin, Tim Northover
Differential Revision: http://reviews.llvm.org/D7166
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227394 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227300 | chandlerc | 2015-01-28 01:52:14 -0800 (Wed, 28 Jan 2015) | 34 lines
[LPM] Rip all of ManagedStatic and ThreadLocal out of the pretty stack
tracing code.
Managed static was just insane overhead for this. We took memory fences
and external function calls in every path that pushed a pretty stack
frame. This includes a multitude of layers setting up and tearing down
passes, the parser in Clang, everywhere. For the regression test suite
or low-overhead JITs, this was contributing to really significant
overhead.
Even the LLVM ThreadLocal is really overkill here because it uses
pthread_{set,get}_specific logic, and has careful code to both allocate
and delete the thread local data. We don't actually want any of that,
and this code in particular has problems coping with deallocation. What
we want is a single TLS pointer that is valid to use during global
construction and during global destruction, any time we want. That is
exactly what every host compiler and OS we use has implemented for
a long time, and what was standardized in C++11. Even though not all of
our host compilers support the thread_local keyword, we can directly use
the platform-specific keywords to get the minimal functionality needed.
Provided this limited trial survives the build bots, I will move this to
Compiler.h so it is more widely available as a light weight if limited
alternative to the ThreadLocal class. Many thanks to David Majnemer for
helping me think through the implications across platforms and craft the
MSVC-compatible syntax.
The end result is *substantially* faster. When running llc in a tight
loop over a small IR file targeting the aarch64 backend, this improves
its performance by over 10% for me. It also seems likely to fix the
remaining regressions seen by JIT users with threading enabled.
This may actually have more impact on real-world compile times due to
the use of the pretty stack tracing utility throughout the rest of Clang
or LLVM, but I've not collected any detailed measurements.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@227332 91177308-0d34-0410-b5e6-96231b3b80d8
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225974 91177308-0d34-0410-b5e6-96231b3b80d8
No functional changes, I'm just going to be doing a lot of work in these files and it would be helpful if they had more current LLVM style.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225817 91177308-0d34-0410-b5e6-96231b3b80d8
This will be used for AMD GPUs with the Graphics Core Next architecture,
which are currently using by the r600 triple.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225276 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a check for underflow when truncating results back to lower
precision at the end of an FMA. The additional sign handling logic in
APFloat::fusedMultiplyAdd should only be performed when the result of the
addition step of the FMA (in full precision) is exactly zero, not when the
result underflows to zero.
Unit tests for this case and related signed zero FMA results are included.
Fixes <rdar://problem/18925551>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225123 91177308-0d34-0410-b5e6-96231b3b80d8
The header claims that this function exists, but the linker wasn't too happy
about it not being in the library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224527 91177308-0d34-0410-b5e6-96231b3b80d8
It makes more sense for ThreadLocal<const T>::get to return a const T*
and ThreadLocal<T>::get to return a T*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224225 91177308-0d34-0410-b5e6-96231b3b80d8
This mirrors the behavior of APInt::udiv and APInt::urem. Some
architectures, like X86, have a single instruction which can compute
both division and remainder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224217 91177308-0d34-0410-b5e6-96231b3b80d8
Clang's static analyzer found several potential cases of undefined
behavior, use of un-initialized values, and potentially null pointer
dereferences in tablegen, Support, MC, and ADT. This cleans them up
with specific assertions on the assumptions of the code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224154 91177308-0d34-0410-b5e6-96231b3b80d8
I didn't notice the problem first because on a non debug build the CRT was
just exiting the process without any message.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224139 91177308-0d34-0410-b5e6-96231b3b80d8
The static analyzer catches a few potential bugs in LLVMSupport. Add
in asserts to silence the warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224044 91177308-0d34-0410-b5e6-96231b3b80d8
This operating system type represents the AMD HSA runtime,
and will be required by the R600 backend in order to generate
correct code for this runtime.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223124 91177308-0d34-0410-b5e6-96231b3b80d8
In both the Unix and Windows variants, std::getenv was called and the
result passed directly to a function accepting a StringRef. This isn't
OK because it might return a null pointer and that causes the StringRef
constructor to assert (and generally produces crash-prone code if
asserts are disabled). Fix this by independently testing the result as
non-null prior to splitting things.
This in turn uncovered another bug in the Unix variant where it would
infinitely recurse if PATH="", or after this fix if PATH isn't set.
There is no need to recurse at all. Slightly re-arrange the code to make
it clear that we can just fixup the Paths argument based on the
environment if we find anything.
I don't know of a particularly useful way to test these routines in
LLVM. I'll commit a test to Clang that ensures that its driver correctly
handles various settings of PATH. However, I have no idea how to
correctly write a Windows test for the PATHEXT change. Any Windows
developers who could provide such a test, please have at. =D
Many thanks to Nick Lewycky and others for helping debug this. =/ It was
quite nasty for us to track down.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223099 91177308-0d34-0410-b5e6-96231b3b80d8
Mark destination buffer in zlib::compress and zlib::decompress as fully
initialized.
When building LLVM with system zlib and MemorySanitizer instrumentation,
MSan does not observe memory writes in zlib code and erroneously considers
zlib output buffers as uninitialized, resulting in false use-of-uninitialized
memory reports. This change helps MSan understand the state of that memory
and prevents such reports.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222763 91177308-0d34-0410-b5e6-96231b3b80d8
"global-init", "global-init-src" and "global-init-type" were originally
used to blacklist entities in ASan init-order checker. However, they
were never documented, and later were replaced by "=init" category.
Old blacklist entries should be converted as follows:
* global-init:foo -> global:foo=init
* global-init-src:bar -> src:bar=init
* global-init-type:baz -> type:baz=init
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222401 91177308-0d34-0410-b5e6-96231b3b80d8
As detailed at http://llvm.org/PR20728, due to an internal overflow in
APFloat::multiplySignificand the APFloat::fusedMultiplyAdd method can return
incorrect results for x87DoubleExtended (x86_fp80) values. This commonly
manifests as incorrect constant folding of libm fmal calls on x86. E.g.
fmal(1.0L, 1.0L, 3.0L) == 0.0L (should be 4.0L)
This patch fixes PR20728 by adding an extra bit to the significand for
intermediate results of APFloat::multiplySignificand, avoiding the overflow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222374 91177308-0d34-0410-b5e6-96231b3b80d8
This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.
This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222334 91177308-0d34-0410-b5e6-96231b3b80d8
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222319 91177308-0d34-0410-b5e6-96231b3b80d8
The triple parser should only accept existing architecture names
when the triple starts with armv, armebv, thumbv or thumbebv.
Patch by Gabor Ballabas.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222129 91177308-0d34-0410-b5e6-96231b3b80d8
warning: suggest parentheses around assignment used as truth value [-Wparentheses]
if (ec = widenPath(path, path_utf16))
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222122 91177308-0d34-0410-b5e6-96231b3b80d8
Fix for LLI failure on Windows\X86: http://llvm.org/PR5053
LLI.exe crashes on Windows\X86 when single precession floating point
intrinsics like the following are used: acos, asin, atan, atan2, ceil,
copysign, cos, cosh, exp, floor, fmin, fmax, fmod, log, pow, sin, sinh,
sqrt, tan, tanh
The above intrinsics are defined as inline-expansions in math.h, and are
not exported by msvcr120.dll (Win32 API GetProcAddress returns null).
For an FREM instruction, the JIT compiler generates a call to a stub for
the fmodf() intrinsic, and adds a relocation to fixup at load time. The
loader searches the libraries for the function, but fails because the
symbol is not exported. So, the call target remains NULL and the
execution crashes.
Since the math functions are loaded at JIT/runtime, the JIT can patch
CALL instruction directly instead of the searching the libraries'
exported symbols. However, this fix caused build failures due to
unresolved symbols like _fmodf at link time.
Therefore, the current fix defines helper functions in the Runtime
link/load library to perform the above operations. The address of these
helper functions are used to patch up the CALL instruction at load time.
Reviewers: lhames, rnk
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D5387
Patch by Swaroop Sridhar!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221947 91177308-0d34-0410-b5e6-96231b3b80d8
Tom Stellard
Daniel Sanders
Hans Wennborg
Chandler Carruth
Chris Bieneman
Lang Hames
Alexey Samsonov
Juergen Ributzka
JF Bastien
Rafael Espindola
David Majnemer
Yaron Keren
Michael Ilseman
Evgeniy Stepanov
Paul Robinson
Matthias Braun
David Blaikie
Michael J. Spencer
Renato Golin
NAKAMURA Takumi
Reid Kleckner