[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
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
GNU libtool checks the output from invoking the linker with --version
and --help, in order to determine the linker "flavour" and the command-
ine arguments to use for various link operations (e.g. generating shared
libraries). To detect GNU ld it looks for the strings "GNU" and
"supported targets:.*elf". Since LLD is compatible with GNU ld we
include those same strings to fool libtool.
Quoting from a comment in the change:
This is somewhat ugly hack, but in reality, we had no choice other
than doing this. Considering the very long release cycle of Libtool,
it is not easy to improve it to recognize LLD as a GNU compatible
linker in a timely manner. Even if we can make it, there are still a
lot of "configure" scripts out there that are generated by old
version of Libtool. We cannot convince every software developer to
migrate to the latest version and re-generate scripts. So we have
this hack.
Upstream LLVM revisions r298532, r298568, r298591
Obtained from: LLVM
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
[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.
[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
[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
The change was made to support glibc and believed to be a no-op on
FreeBSD, but that is not the case for architectures with multiple page
sizes, such as arm64. The relro p_memsz header was rounded up to the
default maximum page size (64K). When 4K pages are in use, multiple
pages beyond the final PT_LOAD segment had their permissions changed to
read-only after application of relocations and copy relocations, which
led to a segfault in certain cases.
This reverts upstream r290986. I have started a discussion about the
upstream fix on the LLVM mailing list.
Reported by: andrew
Sponsored by: The FreeBSD Foundation
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
Fix PR31644 introduced by r287138 and add a regression test.
Thanks Dimitry Andric for the report and fix!
This should restore -MP output to what it was before.
Reported by: jbeich
PR: 216043
The libgcc __register_frame and __deregister_frame functions take a
pointer to a set of FDE/CIEs, terminated by an entry where length is 0.
In Apple's libunwind implementation the pointer is taken to be to a
single FDE. I suspect this was just an Apple bug, compensated by Apple-
specific code in LLVM.
See lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp and
http://lists.llvm.org/pipermail/llvm-dev/2013-April/061737.html
for more detail.
This change is based on the LLVM RTDyldMemoryManager.cpp. It should
later be changed to be alignment-safe.
Reported by: dim
Reviewed by: dim
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8869
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
[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
[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
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
