Commit Graph

204 Commits

Author SHA1 Message Date
Dimitry Andric
554491ffbd Merge ^/head r316992 through r317215. 2017-04-20 21:04:21 +00:00
Dimitry Andric
142446e535 Pull in r300429 from upstream llvm trunk (by Benjamin Kramer):
[X86] Remove special handling for 16 bit for A asm constraints.

  Our 16 bit support is assembler-only + the terrible hack that is
  .code16gcc. Simply using 32 bit registers does the right thing for
  the latter.

  Fixes PR32681.

This fixes some cases of assembling 16 bit code (i.e. SeaBIOS) that uses
the 'A' inline asm constraint, after r316989.

MFC after:	3 days
X-MFC-With:	r316989
2017-04-18 07:02:12 +00:00
Dimitry Andric
7a7e605503 Merge llvm trunk r300422 and resolve conflicts. 2017-04-16 16:25:46 +00:00
Dimitry Andric
86a34ce5a4 Pull in r300404 from upstream llvm trunk (by me):
Use correct registers for "A" inline asm constraint

  Summary:
  In PR32594, inline assembly using the 'A' constraint on x86_64 causes
  llvm to crash with a "Cannot select" stack trace.  This is because
  `X86TargetLowering::getRegForInlineAsmConstraint` hardcodes that 'A'
  means the EAX and EDX registers.

  However, on x86_64 it means the RAX and RDX registers, and on 16-bit
  x86 (ia16?) it means the old AX and DX registers.

  Add new register classes in `X86RegisterInfo.td` to support these
  cases, and amend the logic in `getRegForInlineAsmConstraint` to cope
  with different subtargets.  Also add a test case, derived from
  PR32594.

  Reviewers: craig.topper, qcolombet, RKSimon, ab

  Reviewed By: ab

  Subscribers: ab, emaste, royger, llvm-commits

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

This should fix crashes when using the 'A' constraint on amd64, for
example as it is being used in Xen.

Reported by:	royger
MFC after:	3 days
2017-04-15 22:34:22 +00:00
Dimitry Andric
817a00731b Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release.
We were already very close to the last release candidate, so this is a
pretty minor update.

Relnotes:	yes
MFC after:	1 month
X-MFC-With:	r314564
2017-03-10 19:02:41 +00:00
Dimitry Andric
095282cf35 Reapply r287232 from upstream llvm trunk (by Daniil Fukalov):
[SCEV] limit recursion depth of CompareSCEVComplexity

  Summary:
  CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled
  loop) and runs almost infinite time.

  Added cache of "equal" SCEV pairs to earlier cutoff of further
  estimation. Recursion depth limit was also introduced as a parameter.

  Reviewers: sanjoy

  Subscribers: mzolotukhin, tstellarAMD, llvm-commits

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

Pull in r296992 from upstream llvm trunk (by Sanjoy Das):

  [SCEV] Decrease the recursion threshold for CompareValueComplexity

  Fixes PR32142.

  r287232 accidentally increased the recursion threshold for
  CompareValueComplexity from 2 to 32.  This change reverses that
  change by introducing a separate flag for CompareValueComplexity's
  threshold.

The latter revision fixes the excessive compile times for skein_block.c.
2017-03-06 21:14:20 +00:00
Dimitry Andric
d754696bcb For now, revert r287232 from upstream llvm trunk (by Daniil Fukalov):
[SCEV] limit recursion depth of CompareSCEVComplexity

  Summary:
  CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled
  loop) and runs almost infinite time.

  Added cache of "equal" SCEV pairs to earlier cutoff of further
  estimation. Recursion depth limit was also introduced as a parameter.

  Reviewers: sanjoy

  Subscribers: mzolotukhin, tstellarAMD, llvm-commits

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

This commit is the cause of excessive compile times on skein_block.c
(and possibly other files) during kernel builds on amd64.

We never saw the problematic behavior described in this upstream commit,
so for now it is better to revert it.  An upstream bug has been filed
here: https://bugs.llvm.org/show_bug.cgi?id=32142

Reported by:	mjg
2017-03-05 19:56:20 +00:00
Dimitry Andric
2e477b5e5e Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r296509, and update build glue.
2017-02-28 21:18:23 +00:00
Dimitry Andric
bc93f188f6 Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r296202, and update build glue.
2017-02-25 15:00:57 +00:00
Dimitry Andric
5d19388204 Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r296002, and update build glue.
2017-02-23 19:25:29 +00:00
Dimitry Andric
2bcad0d8d6 Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r295380, and update build glue.
2017-02-17 20:07:35 +00:00
Dimitry Andric
5ca5951e31 Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r294803, and update build glue.
2017-02-11 13:58:05 +00:00
Dimitry Andric
899ca3d65f Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r294123, and update build glue.
2017-02-05 19:57:41 +00:00
Dimitry Andric
c819c1240d Pull in r293773 from upstream llvm trunk (by Sanjay Patel):
[ValueTracking] avoid crashing from bad assumptions (PR31809)

  A program may contain llvm.assume info that disagrees with other
  analysis. This may be caused by UB in the program, so we must not
  crash because of that.

  As noted in the code comments:
  https://llvm.org/bugs/show_bug.cgi?id=31809
  ...we can do better, but this at least avoids the assert/crash in the
  bug report.

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

This fixes an assertion when building editors/emacs-devel.

PR:		216614
2017-02-02 23:01:29 +00:00
Dimitry Andric
077e1117dc Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r293807, and update build glue.
2017-02-01 21:57:07 +00:00
Dimitry Andric
98221d2e7e Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r293443, and update build glue.
2017-01-29 21:56:47 +00:00
Dimitry Andric
f8496407cb Merge llvm, clang, compiler-rt, libc++, lld and lldb release_40 branch
r292951, and update build glue.
2017-01-24 19:56:22 +00:00
Dimitry Andric
e353c0d2f9 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
Dimitry Andric
94c53d4054 Merge llvm, clang, lld and lldb release_40 branch 292732, and update
build glue.
2017-01-22 18:02:44 +00:00
Dimitry Andric
9b1870035a 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
Dimitry Andric
f1a29dd344 Merge llvm, clang, lld and lldb release_40 branch r292009. Also update
build glue.
2017-01-14 22:12:13 +00:00
Dimitry Andric
24e2fe98d0 Merge llvm, clang, lld and lldb trunk r291476. 2017-01-09 22:32:19 +00:00
Dimitry Andric
95ec533a1d Merge llvm, clang, lld and lldb trunk r291274, and resolve conflicts. 2017-01-06 20:24:06 +00:00
Dimitry Andric
e466241c2a Merge llvm, clang, lld and lldb trunk r291015, and resolve conflicts. 2017-01-04 22:29:00 +00:00
Dimitry Andric
8e0f8b8c96 Merge llvm, clang, lld and lldb trunk r291012, and resolve conflicts. 2017-01-04 22:19:42 +00:00
Dimitry Andric
ded09321a8 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
Dimitry Andric
545866cd2e Remove incorrectly merged code fragment. 2017-01-03 18:09:16 +00:00
Dimitry Andric
5bf4713bde Fix line endings (upstream file has CRLF ones). 2017-01-02 22:05:05 +00:00
Dimitry Andric
d88c1a5a57 Update llvm to trunk r290819 and resolve conflicts. 2017-01-02 21:25:48 +00:00
Dimitry Andric
3ffd353070 Merge ^/head r309817 through r310168. 2016-12-16 18:38:31 +00:00
Dimitry Andric
e480fc73f5 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
Dimitry Andric
7a83c005f5 Update llvm, clang, lld, lldb, compiler-rt and libc++ to release_39
branch r288847.
2016-12-10 15:30:39 +00:00
Dimitry Andric
1bde3b7066 Merge ^/head r309519 through r309757. 2016-12-09 20:57:43 +00:00
Dimitry Andric
3157e69de7 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
Dimitry Andric
4dcfa14438 Update llvm, clang, lld and lldb to release_39 branch r288513. 2016-12-02 19:36:28 +00:00
Dimitry Andric
f41fbc90dc Update llvm, clang, lld and lldb to release_39 branch r287912. 2016-11-26 01:02:53 +00:00
Dimitry Andric
11c1fce83a 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
Dimitry Andric
26aa2dc584 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
Dimitry Andric
f1d9b58cd4 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
Dimitry Andric
ffd193b577 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
Dimitry Andric
9dbab393d9 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
Dimitry Andric
82d50f9201 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
Dimitry Andric
1efa33ef28 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
Dimitry Andric
b6054a7b70 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
Dimitry Andric
1f645baf55 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
Dimitry Andric
8f1f370da9 Merge ^/head r305087 through r305219. 2016-09-01 18:16:45 +00:00
Dimitry Andric
1dc088ab69 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
Dimitry Andric
68629f0dce Update llvm to release_39 branch r279689. 2016-08-27 11:51:08 +00:00
Dimitry Andric
fccc5558f5 Update llvm to release_39 branch r279477. 2016-08-24 17:43:08 +00:00
Dimitry Andric
6ca8079c85 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