[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
