Commit Graph

187 Commits

Author SHA1 Message Date
dim
7014fb8e03 Pull in r292758 from upstream llvm trunk (by Sanjay Patel):
[x86] avoid crashing with illegal vector type (PR31672)

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

This fixes an assertion while building graphics/gegl3.

PR:		216166
2017-01-22 18:31:49 +00:00
dim
10de965d53 Merge llvm, clang, lld and lldb release_40 branch 292732, and update
build glue.
2017-01-22 18:02:44 +00:00
dim
be6e2d77e1 Pull in r292133 from upstream llvm trunk (by Hal Finkel):
Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith

  When transferring affected values in the cache from an old value,
  identified by the value of the current callback, to the specified new
  value we might need to insert a new entry into the DenseMap which
  constitutes the cache. Doing so might delete the current callback
  object. Move the copying logic into a new function, a member of the
  assumption cache itself, so that we don't run into UB should the
  callback handle itself be removed mid-copy.

  Differential Revision: https://reviews.llvm.org/D28749

This should fix crashes when building lld (as part of the llvmXY ports).

Reported by:	jbeich
PR:		216117
2017-01-16 19:53:18 +00:00
dim
8b0a30be0e Merge llvm, clang, lld and lldb release_40 branch r292009. Also update
build glue.
2017-01-14 22:12:13 +00:00
dim
618592e561 Merge llvm, clang, lld and lldb trunk r291476. 2017-01-09 22:32:19 +00:00
dim
694712341d Merge llvm, clang, lld and lldb trunk r291274, and resolve conflicts. 2017-01-06 20:24:06 +00:00
dim
5328049929 Merge llvm, clang, lld and lldb trunk r291015, and resolve conflicts. 2017-01-04 22:29:00 +00:00
dim
d0e8f9bf88 Merge llvm, clang, lld and lldb trunk r291012, and resolve conflicts. 2017-01-04 22:19:42 +00:00
dim
d9c0b8b748 Disable PDB support in LLVMSymbolizer for now, to avoid llvm-objdump
pulling in all the PDB handling code.
2017-01-03 20:19:37 +00:00
dim
c52568ef0c Remove incorrectly merged code fragment. 2017-01-03 18:09:16 +00:00
dim
afcae9c519 Fix line endings (upstream file has CRLF ones). 2017-01-02 22:05:05 +00:00
dim
4bdea0916a Update llvm to trunk r290819 and resolve conflicts. 2017-01-02 21:25:48 +00:00
dim
ba1d7aba13 Merge ^/head r309817 through r310168. 2016-12-16 18:38:31 +00:00
dim
dbb7892e50 Tentatively apply https://reviews.llvm.org/D18730 to work around gcc PR
70528 (bogus error: constructor required before non-static data member).
This should fix buildworld with the external gcc package.

Reported by:	https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/
2016-12-10 22:03:44 +00:00
dim
50b03a7e17 Update llvm, clang, lld, lldb, compiler-rt and libc++ to release_39
branch r288847.
2016-12-10 15:30:39 +00:00
dim
cc48a551de Merge ^/head r309519 through r309757. 2016-12-09 20:57:43 +00:00
dim
bb29338288 Pull in r281586 from upstream llvm trunk (by Wei Mi):
Add some shortcuts in LazyValueInfo to reduce compile time of
  Correlated Value Propagation.

  The patch is to partially fix PR10584. Correlated Value Propagation
  queries LVI to check non-null for pointer params of each callsite. If
  we know the def of param is an alloca instruction, we know it is
  non-null and can return early from LVI. Similarly, CVP queries LVI to
  check whether pointer for each mem access is constant. If the def of
  the pointer is an alloca instruction, we know it is not a constant
  pointer. These shortcuts can reduce the cost of CVP significantly.

  Differential Revision: https://reviews.llvm.org/D18066

This significantly reduces memory usage and compilation time when
compiling a particular C++ source file of the graphics/colmap port.

PR:		215136
MFC after:	3 days
2016-12-08 21:02:34 +00:00
dim
9e56742358 Update llvm, clang, lld and lldb to release_39 branch r288513. 2016-12-02 19:36:28 +00:00
dim
c53f65e42d Update llvm, clang, lld and lldb to release_39 branch r287912. 2016-11-26 01:02:53 +00:00
dim
f298a82fda Pull in r283060 from upstream llvm trunk (by Hal Finkel):
[PowerPC] Refactor soft-float support, and enable PPC64 soft float

  This change enables soft-float for PowerPC64, and also makes
  soft-float disable all vector instruction sets for both 32-bit and
  64-bit modes. This latter part is necessary because the PPC backend
  canonicalizes many Altivec vector types to floating-point types, and
  so soft-float breaks scalarization support for many operations. Both
  for embedded targets and for operating-system kernels desiring
  soft-float support, it seems reasonable that disabling hardware
  floating-point also disables vector instructions (embedded targets
  without hardware floating point support are unlikely to have Altivec,
  etc. and operating system kernels desiring not to use floating-point
  registers to lower syscall cost are unlikely to want to use vector
  registers either). If someone needs this to work, we'll need to
  change the fact that we promote many Altivec operations to act on
  v4f32. To make it possible to disable Altivec when soft-float is
  enabled, hardware floating-point support needs to be expressed as a
  positive feature, like the others, and not a negative feature,
  because target features cannot have dependencies on the disabling of
  some other feature. So +soft-float has now become -hard-float.

  Fixes PR26970.

Pull in r283061 from upstream clang trunk (by Hal Finkel):

  [PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float

  Enable soft-float support on PPC64, as the backend now supports it.
  Also, the backend now uses -hard-float instead of +soft-float, so set
  the target features accordingly.

  Fixes PR26970.

Reported by:	Mark Millard
PR:		214433
2016-11-25 18:12:13 +00:00
dim
29bc5ed5ac Pull in r282174 from upstream llvm trunk (by Krzysztof Parzyszek):
[PPC] Set SP after loading data from stack frame, if no red zone is
  present

  Follow-up to r280705: Make sure that the SP is only restored after
  all data is loaded from the stack frame, if there is no red zone.

  This completes the fix for
  https://llvm.org/bugs/show_bug.cgi?id=26519.

  Differential Revision: https://reviews.llvm.org/D24466

Reported by:    Mark Millard
PR:             214433
2016-11-25 18:01:32 +00:00
dim
ff670c67e6 Work around LLVM PR30879, which is about a bad interaction between X86
Call Frame Optimization on i386 and libunwind, by disallowing the
optimization for i386-freebsd12.

This should fix some instances of broken exception handling when frame
pointers are omitted, in particular some unittests run during the build
of editors/libreoffice.

This hack will be removed as soon as upstream has implemented a more
permanent fix for this problem.

Upstream PR:	https://llvm.org/bugs/show_bug.cgi?id=30879
Reviewed by:	emaste
PR:		212343
2016-11-19 21:05:17 +00:00
dim
c080cd6293 Pull in r282336 from upstream llvm trunk (by Sanjay Patel):
[x86] don't try to create a vector integer inst for an SSE1 target
  (PR30512)

  This bug was introduced with:
  http://reviews.llvm.org/rL272511

  We need to restrict the lowering to v4f32 comparisons because that's
  all SSE1 can handle.

  This should fix:
  https://llvm.org/bugs/show_bug.cgi?id=28044

This avoids a "Do not know how to custom type legalize this operation"
error when building the multimedia/ffmpeg port on i386 with SSE enabled.
2016-09-24 20:53:05 +00:00
dim
2dc0915f04 Pull in r280705 from upstream llvm trunk (by Krzysztof Parzyszek):
[PPC] Claim stack frame before storing into it, if no red zone is
  present

  Unlike PPC64, PPC32/SVRV4 does not have red zone. In the absence of
  it there is no guarantee that this part of the stack will not be
  modified by any interrupt. To avoid this, make sure to claim the
  stack frame first before storing into it.

  This fixes https://llvm.org/bugs/show_bug.cgi?id=26519.

  Differential Revision: https://reviews.llvm.org/D24093
2016-09-10 16:51:39 +00:00
dim
1b67a5334b Pull in r280350 from upstream llvm trunk (by Hal Finkel):
Add ISD::EH_DWARF_CFA, simplify @llvm.eh.dwarf.cfa on Mips, fix on
  PowerPC

  LLVM has an @llvm.eh.dwarf.cfa intrinsic, used to lower the
  GCC-compatible __builtin_dwarf_cfa() builtin. As pointed out in
  PR26761, this is currently broken on PowerPC (and likely on ARM as
  well). Currently, @llvm.eh.dwarf.cfa is lowered using:

    ADD(FRAMEADDR, FRAME_TO_ARGS_OFFSET)

  where FRAME_TO_ARGS_OFFSET defaults to the constant zero. On x86,
  FRAME_TO_ARGS_OFFSET is lowered to 2*SlotSize. This setup, however,
  does not work for PowerPC. Because of the way that the stack layout
  works, the canonical frame address is not exactly (FRAMEADDR +
  FRAME_TO_ARGS_OFFSET) on PowerPC (there is a lower save-area offset
  as well), so it is not just a matter of implementing
  FRAME_TO_ARGS_OFFSET for PowerPC (unless we redefine its semantics --
  We can do that, since it is currently used only for
  @llvm.eh.dwarf.cfa lowering, but the better to directly lower the CFA
  construct itself (since it can be easily represented as a
  fixed-offset FrameIndex)). Mips currently does this, but by using a
  custom lowering for ADD that specifically recognizes the (FRAMEADDR,
  FRAME_TO_ARGS_OFFSET) pattern.

  This change introduces a ISD::EH_DWARF_CFA node, which by default
  expands using the existing logic, but can be directly lowered by the
  target. Mips is updated to use this method (which simplifies its
  implementation, and I suspect makes it more robust), and updates
  PowerPC to do the same.

  Fixes PR26761.

  Differential Revision: https://reviews.llvm.org/D24038
2016-09-10 16:11:42 +00:00
dim
9b709e36e6 Pull in r280188 from upstream llvm trunk (by Hal Finkel):
[PowerPC] Don't spill the frame pointer twice

  When a function contains something, such as inline asm, which
  explicitly clobbers the register used as the frame pointer, don't
  spill it twice. If we need a frame pointer, it will be saved/restored
  in the prologue/epilogue code.  Explicitly spilling it again will
  reuse the same spill slot used by the prologue/epilogue code, thus
  clobbering the saved value. The same applies to the base-pointer or
  PIC-base register.

  Partially fixes PR26856. Thanks to Ulrich for his analysis and the
  small inline-asm reproducer.
2016-09-10 15:44:00 +00:00
dim
94e48c1239 Pull in r280040 from upstream llvm trunk (by Hal Finkel):
[PowerPC] Add support for -mlongcall

  The "long call" option forces the use of the indirect calling
  sequence for all calls (even those that don't really need it). GCC
  provides this option; This is helpful, under certain circumstances,
  for building very-large binaries, and some other specialized use
  cases.

  Fixes PR19098.

Pull in r280041 from upstream clang trunk (by Hal Finkel):

  [PowerPC] Add support for -mlongcall

  Add support for GCC's PowerPC -mlongcall option; the backend supports
  the corresponding target feature as of r280040.

  Fixes PR19098.
2016-09-10 15:38:46 +00:00
dim
ea46576d2d Pull in r280837 from upstream llvm trunk (by Wei Mi):
Don't reduce the width of vector mul if the target doesn't support
  SSE2.

  The patch is to fix PR30298, which is caused by rL272694. The
  solution is to bail out if the target has no SSE2.

  Differential Revision: https://reviews.llvm.org/D24288

This fixes building the multimedia/libx264 port on i386.
2016-09-07 20:36:13 +00:00
dim
bfc7120155 Merge ^/head r305087 through r305219. 2016-09-01 18:16:45 +00:00
dim
356d97c3cb Pull in r277331 from upstream llvm trunk (by Diana Picus):
[AArch64] Return the correct size for TLSDESC_CALLSEQ

  The branch relaxation pass is computing the wrong offsets because it assumes
  TLSDESC_CALLSEQ eats up 4 bytes, when in fact it is lowered to an instruction
  sequence taking up 16 bytes. This can become a problem in huge files with lots
  of TLS accesses, as it may slowly move branch targets out of the range computed
  by the branch relaxation pass.

  Fixes PR24234 https://llvm.org/bugs/show_bug.cgi?id=24234

  Differential Revision: https://reviews.llvm.org/D22870

This fixes "error in backend: fixup value out of range" when compiling
the misc/talkfilters port for AArch64.

Reported by:	sbruno
PR:		201762
MFC after:	3 days
2016-09-01 18:11:44 +00:00
dim
4354b878f3 Update llvm to release_39 branch r279689. 2016-08-27 11:51:08 +00:00
dim
c6573a90f0 Update llvm to release_39 branch r279477. 2016-08-24 17:43:08 +00:00
dim
8f38cfd8d9 Pull in r265122 from upstream llvm trunk (by James Molloy):
Fix for pr24346: arm asm label calculation error in sub

  Some ARM instructions encode 32-bit immediates as a 8-bit integer
  (0-255) and a 4-bit rotation (0-30, even) in its least significant 12
  bits. The original fixup, FK_Data_4, patches the instruction by the
  value bit-to-bit, regardless of the encoding. For example, assuming
  the label L1 and L2 are 0x0 and 0x104 respectively, the following
  instruction:

    add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260

  would be assembled to the following, which adds 1 to r0, instead of
  260:

    e2800104 add r0, r0, #4, 2 ; equivalently 1

  The new fixup kind fixup_arm_mod_imm takes care of the encoding:

    e2800f41 add r0, r0, #260

  Patch by Ting-Yuan Huang!

This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.

Requested by:	jkim
MFC after:	3 days
2016-08-20 14:04:51 +00:00
dim
84024f61ce Pull in r262772 from upstream clang trunk (by Simon Pilgrim):
[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

  btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
  support XSAVE.

  Differential Revision: http://reviews.llvm.org/D17682

Pull in r262782 from upstream llvm trunk (by Simon Pilgrim):

  [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

  btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
  support XSAVE.

  Differential Revision: http://reviews.llvm.org/D17683

This ensures clang does not emit AVX instructions for CPUTYPE=btver1.

Reported by:	Michel Depeige <demik+freebsd@lostwave.net>
PR:		211864
MFC after:	3 days
2016-08-17 21:57:11 +00:00
dim
3d8083fcb6 Update llvm to release_39 branch r278877. 2016-08-17 19:41:29 +00:00
dim
1070bea400 Update llvm to release_39 branch r276489, and resolve conflicts. 2016-08-16 21:02:59 +00:00
dim
370a96c692 Pull in r271548 from upstream llvm trunk (by me):
Only attempt to detect AVG if SSE2 is available

  Summary:
  In PR29973 Sanjay Patel reported an assertion failure when a certain
  loop was optimized, for a target without SSE2 support.  It turned out
  this was because of the AVG pattern detection introduced in rL253952.

  Prevent the assertion failure by bailing out early in
  `detectAVGPattern()`, if the target does not support SSE2.

  Also add a minimized test case.

  Reviewers: congh, eli.friedman, spatel

  Subscribers: emaste, llvm-commits

  Differential Revision: http://reviews.llvm.org/D20905

This should fix assertion failures ("Requires at least SSE2!") when
building the games/0ad port with CPUTYPE=pentium3.

Reported by:	madpilot
2016-06-02 19:54:38 +00:00
dim
87ea0ad898 Pull in r269908 from upstream llvm trunk (by James Molloy):
[VectorUtils] Fix nasty use-after-free

  In truncateToMinimalBitwidths() we were RAUW'ing an instruction then
  erasing it. However, that intruction could be cached in the map we're
  iterating over. The first check is "I->use_empty()" which in most
  cases would return true, as the (deleted) object was RAUW'd first so
  would have zero use count. However in some cases the object could
  have been polluted or written over and this wouldn't be the case.
  Also it makes valgrind, asan and traditionalists who don't like their
  compiler to crash sad.

  No testcase as there are no externally visible symptoms apart from a
  crash if the stars align.

  Fixes PR26509.

This should fix crashes when building a number of ports on arm64.

Reported by:	andrew
2016-05-29 20:54:16 +00:00
dim
9de2279aa4 Pull in r264465 from upstream llvm trunk (by David Majnemer):
[X86] Emit a proper ADJCALLSTACKDOWN in EmitLoweredTLSAddr

  We forgot to add the second machine operand to our ADJCALLSTACKDOWN,
  resulting in crashes in PEI.

  This fixes PR27071.

This should fix an assertion failure during buildworld, when using -Os,
and targeting either i386 directly, or building the 32-bit libraries on
amd64.

Reported by:	Eric Camachat <eric.camachat@gmail.com>
2016-03-26 17:38:15 +00:00
dim
aad574545e Convert two llvm source files to native line ending, which was also done
upstream.  Merging doesn't automatically do this, unfortunately.
2016-03-05 21:10:34 +00:00
dim
7964a6d9e9 Update llvm and clang to release_38 branch r261684. 2016-02-24 22:07:56 +00:00
dim
72672a13f9 Undo r295543, since the shrink wrapping bug was fixed upstream by Davide
Italiano and Quentin Colombet.
2016-02-24 21:41:28 +00:00
dim
5082f936dc Update llvm and clang to release_38 branch r261369. 2016-02-21 16:23:44 +00:00
dim
7024e27dde Update llvm, clang and lldb to release_38 branch r260756. 2016-02-13 15:58:51 +00:00
dim
86bef0867f For now, disable shrink-wrapping (a new optimization pass that computes
the safe point to insert the prologue and epilogue of the function) on
X86.  This prevents problems with some functions using TLS, such as in
jemalloc, and which was the cause for Address Sanitizer crashes.  The
correct fix is still being discussed upstream.
2016-02-11 20:00:22 +00:00
dim
2c8b377010 Update llvm, clang and lldb to release_38 branch r258968. 2016-01-27 22:48:52 +00:00
dim
6e0d73d099 Update llvm and clang to release_38 branch r258549. 2016-01-22 21:50:08 +00:00
dim
815e5f1f97 Pull in r257977 from upstream llvm trunk, by Keno Fischer:
[DwarfDebug] Move MergeValues to .cpp, NFC

Pull in r257979 from upstream llvm trunk, by Keno Fischer:

  [DwarfDebug] Don't merge DebugLocEntries if their pieces overlap

  Summary:
  Later in DWARF emission we check that DebugLocEntries have
  non-overlapping pieces, so we should create any such entries
  by merging here.

  Fixes PR26163.

  Reviewers: aprantl
  Differential Revision: http://reviews.llvm.org/D16249

Again, these will be merged to the official release_38 branch soon, but
we need them ASAP.
2016-01-16 18:04:22 +00:00
dim
a49d5469df Pull in r257902 from upstream llvm trunk, by James Y Knight (this will
be merged to the official release_38 branch soon, but we need it ASAP):

  Stop increasing alignment of externally-visible globals on ELF
  platforms.

  With ELF, the alignment of a global variable in a shared library will
  get copied into an executables linked against it, if the executable even
  accesss the variable. So, it's not possible to implicitly increase
  alignment based on access patterns, or you'll break existing binaries.

  This happened to affect libc++'s std::cout symbol, for example. See
  thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311

  (This is a re-commit of r257719, without the bug reported in
  PR26144. I've tweaked the code to not assert-fail in
  enforceKnownAlignment when computeKnownBits doesn't recurse far enough
  to find the underlying Alloca/GlobalObject value.)

  Differential Revision: http://reviews.llvm.org/D16145
2016-01-16 18:00:58 +00:00
dim
7c048a3e43 Undo r289072, which reverted upstream llvm trunk r240144. This is going
to be fixed for real by importing upstream llvm trunk r257902.
2016-01-16 17:57:54 +00:00