------------------------------------------------------------------------
r261384 | qcolombet | 2016-02-19 16:32:29 -0800 (Fri, 19 Feb 2016) | 4 lines

[RegAllocFast] Properly track the physical register definitions on calls.

PR26485

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@261539 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------
r261387 | davide | 2016-02-19 16:44:47 -0800 (Fri, 19 Feb 2016) | 8 lines

[X86ISelLowering] Fix TLSADDR lowering when shrink-wrapping is enabled.

TLSADDR nodes are lowered into actuall calls inside MC. In order to prevent
shrink-wrapping from pushing prologue/epilogue past them (which result
in TLS variables being accessed before the stack frame is set up), we 
put markers, so that the stack gets adjusted properly.
Thanks to Quentin Colombet for guidance/help on how to fix this problem!

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@261542 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------
r261441 | nemanjai | 2016-02-20 10:16:25 -0800 (Sat, 20 Feb 2016) | 12 lines

Fix for PR 26500

This patch corresponds to review:
http://reviews.llvm.org/D17294

It ensures that whatever block we are emitting the prologue/epilogue into, we
have the necessary scratch registers. It takes away the hard-coded register
numbers for use as scratch registers as registers that are guaranteed to be
available in the function prologue/epilogue are not guaranteed to be available
within the function body. Since we shrink-wrap, the prologue/epilogue may end
up in the function body.
------------------------------------------------------------------------

------------------------------------------------------------------------
r261447 | nemanjai | 2016-02-20 12:45:37 -0800 (Sat, 20 Feb 2016) | 6 lines

Fix the build bot break caused by rL261441.

The patch has a necessary call to a function inside an assert. Which is fine
when you have asserts turned on. Not so much when they're off. Sorry about
the regression.
------------------------------------------------------------------------

------------------------------------------------------------------------
r261546 | nemanjai | 2016-02-22 10:04:00 -0800 (Mon, 22 Feb 2016) | 6 lines

Fix for PR26690 take 2

This is what was meant to be in the initial commit to fix this bug. The
parens were missing. This commit also adds a test case for the bug and
has undergone full testing on PPC and X86.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@261572 91177308-0d34-0410-b5e6-96231b3b80d8

This adapts r261349 to the release branch.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@261586 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@262074 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@262496 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@262537 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@262542 91177308-0d34-0410-b5e6-96231b3b80d8

…builds with assertions enabld

Since the PassInfo cache does a regular, uncached, slow lookup for the
asserted condition, it's not very effective *cough* when assertions are
enabled. Since disabling these assertions gives quite a nice perf boost
and it's not really worse than the patch we had previously, let's just
do that.

Original patch by Nathaniel Theis

Apparently there's a bug in older clang versions which rejects this code, and
the fix is to just remove the override keyword for now. This is tracked in this
llvm bug:

  https://llvm.org/bugs/show_bug.cgi?id=22619

…m.assume()

intrinsics in the target-independent FastISel.

Our cleanups do not support true lexical nesting of funclets which
obviates the need to perform state stores.

This fixes PR26361.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259161 91177308-0d34-0410-b5e6-96231b3b80d8

As of the time of this writing it's not actually used anywhere meaningfullly
throughout the LLVM repo that we need, and it unfortunately uses `std::thread`
which isn't available in mingw-w64 toolchains with the win32 threading model
(the one that we use).

Two major changes were made to achieve this:

1. The `ThreadPool.cpp` file was just entirely commented out. This isn't used
   anywhere in the LLVM repo nor in Rust itself.
2. The `ParallelCG.cpp` file was mostly deleted. Unfortunately it's used a few
   places in LLVM and is needed to link correctly, but we in Rust don't use it
   at all. For now it's just a stub implementation that hopefully compiles
   everywhere, but perhaps we can find a less invasive (aka doesn't have rebase
   conflicts in the future) change to apply soon.

For reference, the upstream LLVM bug has been reported [1]

[1]: https://llvm.org/bugs/show_bug.cgi?id=26365

* When testing whether we need to pass `-Wl,-z,defs` the cmake files currently
  tests for FreeBSD, but only if the host system is FreeBSD. Instead we should
  test whether the target that we're compiling is FreeBSD so we correctly deduce
  that it should not be passed.

* The `PATH_MAX` constant is defined in a different place for the dsymutil tool,
  so we just config that code out for now as it apparently doesn't include the
  right header?