[InstCombine] Disable some portions of foldGEPICmp for GEPs that
return a vector of pointers. Fix other portions.
llvm-svn: 370114
This should fix instances of 'Assertion failed: (isa<X>(Val) &&
"cast<Ty>() argument of incompatible type!"), function cast, file
/usr/src/contrib/llvm/include/llvm/Support/Casting.h, line 255', when
building openjdk8 for aarch64 and armv7.
Reported by: jbeich
PR: 236566
MFC after: 3 days
/proc/curproc/file and the KERN_PROC_PATHNAME sysctl may not return the
desired path if there are multiple hardlinks to the file.
PR: 241932
Tested by: ler
Sponsored by: The FreeBSD Foundation
[RISCV] Add Custom Parser for Atomic Memory Operands
Summary:
GCC Accepts both (reg) and 0(reg) for atomic instruction memory
operands. These instructions do not allow for an offset in their
encoding, so in the latter case, the 0 is silently dropped.
Due to how we have structured the RISCVAsmParser, the easiest way to
add support for parsing this offset is to add a custom AsmOperand and
parser. This parser drops all the parens, and just keeps the
register.
This commit also adds a custom printer for these operands, which
matches the GCC canonical printer, printing both `(a0)` and `0(a0)`
as `(a0)`.
Reviewers: asb, lewis-revill
Reviewed By: asb
Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook,
apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay,
zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o,
rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65205
llvm-svn: 367553
Merge commit f596f4507 from llvm git (by Sam Elliott):
[RISCV] Add FreeBSD targets
Reviewers: asb
Reviewed By: asb
Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne,
emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57795
Patch by James Clarke (jrtc27)
llvm-svn: 367557
Merge commit f596f4507 from llvm git (by Hsiangkai Wang):
[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.
It is necessary to generate fixups in .debug_frame or .eh_frame as
relaxation is enabled due to the address delta may be changed after
relaxation.
There is an opcode with 6-bits data in debug frame encoding. So, we
also need 6-bits fixup types.
Differential Revision: https://reviews.llvm.org/D58335
llvm-svn: 366524
Merge commit f596f4507 from llvm git (by Hsiangkai Wang):
[DebugInfo] Some fields do not need relocations even relax is enabled.
In debug frame information, some fields, e.g., Length in CIE/FDE and
Offset in FDE are attributes to describe the structure of CIE/FDE.
They are not related to the relaxed code. However, these attributes
are symbol differences. So, in current design, these attributes will
be filled as zero and LLVM generates relocations for them.
We only need to generate relocations for symbols in executable
sections. So, if the symbols are not located in executable sections,
we still evaluate their values under relaxation.
Differential Revision: https://reviews.llvm.org/D61584
llvm-svn: 366531
Merge commit f596f4507 from llvm git (by Alex Bradbury):
[RISCV] Don't force absolute FK_Data_X fixups to relocs
The current behavior of shouldForceRelocation forces relocations for
the majority of fixups when relaxation is enabled. This makes sense
for fixups which incorporate symbols but is unnecessary for simple
data fixups where the fixup target is already resolved to an absolute
value.
Differential Revision: https://reviews.llvm.org/D63404
Patch by Edward Jones.
llvm-svn: 369257
Merge commit f596f4507 from llvm git (by Alex Bradbury):
[RISCV] Implement getExprForFDESymbol to ensure RISCV_32_PCREL is
used for the FDE location
Follow binutils in using RISCV_32_PCREL for the FDE initial location.
As explained in the relevant binutils commit
<a6cbf936e3>,
the ADD/SUB pair of relocations is problematic in the presence of
linker relaxation.
This patch has the same end goal as D64715 but includes test changes
and avoids adding a new global VariantKind to MCExpr.h (preferring
RISCVMCExpr VKs like the rest of the RISC-V backend).
Differential Revision: https://reviews.llvm.org/D66419
llvm-svn: 369375
This series of merges will permit riscv64 kernels and riscv64sf worlds
to build with clang instead of gcc (but still using the bfd linker).
Requested by: jhb
Obtained from: https://github.com/freebsd/freebsd/compare/master...bsdjhb:riscv_clang
MFC after: 1 month
X-MFC-With: r353358
[x86] avoid crashing when splitting AVX stores with non-simple type
(PR43916)
The store splitting transform was assuming a simple type (MVT), but
that's not necessarily the case as shown in the test.
This should fix 'Assertion failed: (isSimple() && "Expected a
SimpleValueType!")' when building the security/openssl111 port targeting
a CPU that supports AVX, but not AVX2, such as sandybridge.
PR: 241747
MFC after: 1 month
X-MFC-With: r353358
There doesn't seem to be much sense in defaulting "on" unwind tables on
amd64 and not on other arches. It causes surprising differences between
platforms, such as the PR below.
Prior to this change, FreeBSD inherited the default implementation of the
method from the Gnu.h Generic_Elf => Generic_GCC parent class, which
returned true only for amd64 targets. Override that and opt on always,
similar to, e.g., NetBSD.
PR: 241562
Reported by: lwhsu
Reviewed by: dim
Discussed with: emaste
MFC after: I'm not going to, but you should feel free
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D22252
[PowerPC] Do not emit HW loop if the body contains calls to
lrint/lround
These two intrinsics are lowered to calls so should prevent the
formation of CTR loops. In a subsequent patch, we will handle all
currently known intrinsics and prevent the formation of HW loops if
any unknown intrinsics are encountered.
Differential revision: https://reviews.llvm.org/D68841
This should fix an "invalid CRT loop" assertion when building the
www/node port for powerpc64.
Requested by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>
MFC after: 1 month
X-MFC-With: r353358
Revert rL349624 : Let TableGen write output only if it changed,
instead of doing so in cmake, attempt 2
Differential Revision: https://reviews.llvm.org/D55842
-----------------
As discussed on PR43385 this is causing Visual Studio msbuilds to
perpetually rebuild all tablegen generated files
Pull in r373664 from upstream llvm trunk (by Nico Weber):
Reland r349624: Let TableGen write output only if it changed, instead
of doing so in cmake
Move the write-if-changed logic behind a flag and don't pass it with
the MSVC generator. msbuild doesn't have a restat optimization, so
not doing write-if-change there doesn't have a cost, and it should
fix whatever causes PR43385.
This should fix the scenario where an incremental build from before
r353358 (the clang 9.0.0 upgrade) to r353358 or later fails to update
the timestamp of the generated lib/clang/headers/arm_fp16.h header.
After such a build, installing world from read-only source and object
directories would attempt to generate the header again, leading to
"clang-tblgen: error opening arm_fp16.h.d:Read-only file system".
Reported by: avg, np
PR: 241402
MFC after: 1 month
X-MFC-With: r353358
[ARM] VFPv2 only supports 16 D registers.
r361845 changed the way we handle "D16" vs. "D32" targets; there used
to be a negative "d16" which removed instructions from the
instruction set, and now there's a "d32" feature which adds
instructions to the instruction set. This is good, but there was an
oversight in the implementation: the behavior of VFPv2 was changed.
In particular, the "vfp2" feature was changed to imply "d32". This is
wrong: VFPv2 only supports 16 D registers.
In practice, this means if you specify -mfpu=vfpv2, the compiler will
generate illegal instructions.
This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2"
and "vfp2sp" so they don't imply "d32".
Differential Revision: https://reviews.llvm.org/D67375
Pull in r372187 from upstream clang trunk (by Eli Friedman):
[ARM] Update clang for removal of vfp2d16 and vfp2d16sp
Matching fix for https://reviews.llvm.org/D67375 (r372186).
Differential Revision: https://reviews.llvm.org/D67467
This should fix clang generating invalid opcodes for floating point
operations on armv6.
Requested by: mmel
MFC after: 3 days
i686, as per the discussion on the freebsd-arch mailing list. Earlier
in r352030, I had already bumped it to i586, to work around missing
atomic 64 bit functions for the i386 architecture.
Relnotes: yes
Fix process launch failure on FreeBSD after r365761
Summary:
After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS`
enabled, launching any process on FreeBSD crashes lldb with:
```
Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in
success mode must still be checked prior to being destroyed).
```
This is because `m_operation_thread` and `m_monitor_thread` were
wrapped in `llvm::Expected<>`, but this requires the objects to be
correctly initialized before accessing them.
To fix the crashes, use `llvm::Optional<>` for the members (as
indicated by labath), and use local variables to store the return
values of `LaunchThread` and `StartMonitoringChildProcess`. Then,
only assign to the member variables after checking if the return
values indicated success.
Reviewers: devnexen, emaste, MaskRay, mgorny
Reviewed By: devnexen
Subscribers: jfb, labath, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D68723
PR: 241137
MFC after: 1 month
X-MFC-With: r353358
Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be
checked before access or destruction" when launching executables, while
we sort this out with upstream.
PR: 241137
MFC after: 1 month
X-MFC-With: r353358
checked before access or destruction" when launching executables, while
we sort this out with upstream.
Reported by: jbeich
PR: 241137
MFC after: 1 month
X-MFC-With: r353358
[x86] fix assert with horizontal math + broadcast of vector (PR43402)
https://bugs.llvm.org/show_bug.cgi?id=43402
This should fix 'Assertion failed: ((HOp.getValueType() == MVT::v2f64 ||
HOp.getValueType() == MVT::v4f64) && HOp.getValueType() == VT &&
"Unexpected type for h-op"), function foldShuffleOfHorizOp, file
contrib/llvm/lib/Target/X86/X86ISelLowering.cpp, line 33661' when
building the devel/llvm90 port with CPUTYPE=haswell.
PR: 240759
[mips] Deduce MIPS specific ELF header flags from `emulation`
In case of linking binary blobs which do not have any ELF headers, we
can deduce MIPS ABI ELF header flags from an `emulation` option.
Patch by Kyle Evans.
Requested by: kevans :)
When evaluating a __builtin_constant_p conditional, always enter
constant-folding mode regardless of the original evaluation mode.
In order for this to be correct, we need to track whether we're
checking for a potential constant expression or checking for
undefined behavior separately from the evaluation mode enum, since we
don't want to clobber those states when entering constant-folding
mode.
This should fix "ld: error: undefined symbol: ix86_isa_flags" (and many
other symbol names) during the initial stages of the lang/gcc* ports.
The issue was that without optimization, the __builtin_constant_p()
expressions generated in gencondmd.c would emit references to global
variables that were undefined, such as ix86_isa_flags.
PR: 240629
Add -m(no)-spe to clang
Summary:
r337347 added support for the Signal Processing Engine (SPE) to LLVM.
This follows that up with the clang side.
This adds -mspe and -mno-spe, to match GCC.
Subscribers: nemanjai, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D49754
Re-commit r357452 (take 3): "SimplifyCFG
SinkCommonCodeFromPredecessors: Also sink function calls without used
results (PR41259)"
Third time's the charm.
This was reverted in r363220 due to being suspected of an internal
benchmark regression and a test failure, none of which turned out to
be caused by this.
As reported in https://bugs.llvm.org/show_bug.cgi?id=43269, this causes
UNREACHABLE errors when compiling if_malo_pci.c for arm and aarch64.
change https://reviews.llvm.org/rL356631 ("[X86] Add CMPXCHG8B feature
flag. Set it for all CPUs except i386/i486 including 'generic'. Disable
use of CMPXCHG8B when this flag isn't set"), clang now correctly emits
calls to __atomic_load_8, __atomic_store_8, etc. when targeting i486,
and this means we can no longer link most modern programs, because we do
not have a libatomic, nor support for atomic functions in libc. See
also PR 230888, 220822, 233725, 234976, and more probably duplicates.
Note that in practice, clang has been incorrectly generating cmpxchg8b
instructions for years now, when targeting i486. So de facto nothing
really changes by doing this.
[PPC32] Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO
Unlike ppc64, which has ADDISgotTprelHA+LDgotTprelL pairs, ppc32 just
uses LDgotTprelL32, so it does not make lots of sense to use _LO
without a paired _HA.
Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO to match GCC, and
get better linker relocation check. Note, R_PPC_GOT_TPREL16_{HA,LO}
don't have good linker support:
(a) lld does not support R_PPC_GOT_TPREL16_{HA,LO}.
(b) Top of tree ld.bfd does not support R_PPC_GOT_REL16_HA
Initial-Exec -> Local-Exec relaxation:
// a.o
addis 3, 3, tsd_tls@got@tprel@ha
lwz 3, tsd_tls@got@tprel@l(3)
add 3, 3, tsd_tls@tls
// b.o
.section .tdata,"awT"; .globl tsd_tls; tsd_tls:
// ld/ld-new a.o b.o
internal error, aborting at ../../bfd/elf32-ppc.c:7952 in
ppc_elf_relocate_section
Reviewed By: adalava
Differential Revision: https://reviews.llvm.org/D66925
This allows use of LLD for linking 32-bit static binaries on
FreeBSD/powerpc.
Submitted by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>
[IfConversion] Fix diamond conversion with unanalyzable branches.
The code was incorrectly counting the number of identical
instructions, and therefore tried to predicate an instruction which
should not have been predicated. This could have various effects: a
compiler crash, an assembler failure, a miscompile, or just
generating an extra, unnecessary instruction.
Instead of depending on TargetInstrInfo::removeBranch, which only
works on analyzable branches, just remove all branch instructions.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43121 and
https://bugs.llvm.org/show_bug.cgi?id=41121 .
Differential Revision: https://reviews.llvm.org/D67203
This should fix "Unable to predicate BX killed renamable $r0" errors
when building the lang/spidermonkey170 and lang/spidermonkey38 ports for
armv7 and armv6.
PR: 236567
MFC after: 3 days
[ELF] Align the first section of a PT_LOAD even if its type is
SHT_NOBITS
Reported at https://reviews.llvm.org/D64930#1642223
If the only section of a PT_LOAD is a SHT_NOBITS section (e.g. .bss),
we may not align its sh_offset. p_offset of the PT_LOAD will be set
to sh_offset, and we will get p_offset!=p_vaddr (mod p_align). If
such executable is mapped by the Linux kernel, it will segfault.
After D64906, this may happen the non-linker script case.
The linker script case has had this issue for a long time. This was
fixed by rL321657 (but the test linkerscript/nobits-offset.s failed
to test a SHT_NOBITS section), but broken by rL345154.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D66658
Pull in r371013 from upstream lld trunk (by Rui Ueyama):
Align output segments correctly
Previously, segments were aligned according to their first section's
alignment requirements. That was not correct, but segments are also
aligned to a page boundary, and a page boundary is usually much
larger than a section alignment requirement, so no one noticed this
bug before.
Now, lld has --nmagic option which sets maxPageSize to 1 to
effectively disable page alignment, which reveals the issue.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43212
Differential Revision: https://reviews.llvm.org/D67152
Together, these should ensure gpboot.out gets a correctly aligned offset
for its .rodata section, and fix "layout constraint violation" errors
from objcopy.
lldb prepends the thread name to log entries, and the existing thread
name for the FreeBSD ProcessMonitor thread was longer than the kernel's
supported thread name length, and so was truncated. This made logs hard
to read, as the truncated thread name ran into the log message. Shorten
"lldb.process.freebsd.operation" to just "freebsd.op" so that logs are
more readable.
(Upstreaming to lldb still to be done).
This is a backport of LLVM commit 8331f61a51a7a0a1efbf5ed398e181593023d151,
llvm-svn: 353981:
ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an
IRELATIVE where possible.
This is needed in order to make ifuncs work correctly on PPC64.
It fixes an issue with lld, in which it would skip emitting necessary IRELATIVE
relocations. Without this change, indirect calls to ifuncs would result in a
segmentation fault, in static binaries or when defined in the main binary
(outside shared libraries).
This change also reverts the local
"Preserve relocations against ifuncs when -zifunc-noplt" commit and
replaces it by its upstream version, as part of the merge.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D21102
[CodeGen][NFC] Simplify checks for stack protector index checking
Use `hasStackProtectorIndex()` instead of `getStackProtectorIndex()
>= 0`.
Pull in r366371 from upstream llvm trunk (by Francis Visoiu Mistrih):
[PEI] Don't re-allocate a pre-allocated stack protector slot
The LocalStackSlotPass pre-allocates a stack protector and makes sure
that it comes before the local variables on the stack.
We need to make sure that later during PEI we don't re-allocate a new
stack protector slot. If that happens, the new stack protector slot
will end up being **after** the local variables that it should be
protecting.
Therefore, we would have two slots assigned for two different stack
protectors, one at the top of the stack, and one at the bottom. Since
PEI will overwrite the assigned slot for the stack protector, the
load that is used to compare the value of the stack protector will
use the slot assigned by PEI, which is wrong.
For this, we need to check if the object is pre-allocated, and re-use
that pre-allocated slot.
Differential Revision: https://reviews.llvm.org/D64757
Pull in r367068 from upstream llvm trunk (by Francis Visoiu Mistrih):
[CodeGen] Don't resolve the stack protector frame accesses until PEI
Currently, stack protector loads and stores are resolved during
LocalStackSlotAllocation (if the pass needs to run). When this is the
case, the base register assigned to the frame access is going to be
one of the vregs created during LocalStackSlotAllocation. This means
that we are keeping a pointer to the stack protector slot, and we're
using this pointer to load and store to it.
In case register pressure goes up, we may end up spilling this
pointer to the stack, which can be a security concern.
Instead, leave it to PEI to resolve the frame accesses. In order to
do that, we make all stack protector accesses go through frame index
operands, then PEI will resolve this using an offset from sp/fp/bp.
Differential Revision: https://reviews.llvm.org/D64759
Together, these fix a issue where the stack protection feature in LLVM's
ARM backend can be rendered ineffective when the stack protector slot is
re-allocated so that it appears after the local variables that it is
meant to protect, leaving the function potentially vulnerable to a
stack-based buffer overflow.
Reported by: andrew
Security: https://kb.cert.org/vuls/id/129209/
MFC after: 3 days
8.0.1 final release r366581. The only functional change is a fix for a
mismerge of upstream r360816, which properly restores the r2 register
when unwinding on PowerPC64 (See https://reviews.freebsd.org/D20337).
Relnotes: yes
PR: 236062
MFC after: 3 days
X-MFC-With: r349004
[ELF] Handle non-glob patterns before glob patterns in version
scripts & fix a corner case of --dynamic-list
This fixes PR38549, which is silently accepted by ld.bfd.
This seems correct because it makes sense to let non-glob patterns
take precedence over glob patterns.
lld issues an error because
`assignWildcardVersion(ver, VER_NDX_LOCAL);` is processed before
`assignExactVersion(ver, v.id, v.name);`.
Move all assignWildcardVersion() calls after assignExactVersion()
calls to fix this.
Also, move handleDynamicList() to the bottom. computeBinding() called
by includeInDynsym() has this cryptic rule:
if (versionId == VER_NDX_LOCAL && isDefined() && !isPreemptible)
return STB_LOCAL;
Before the change:
* foo's version is set to VER_NDX_LOCAL due to `local: *`
* handleDynamicList() is called
- foo.computeBinding() is STB_LOCAL
- foo.includeInDynsym() is false
- foo.isPreemptible is not set (wrong)
* foo's version is set to V1
After the change:
* foo's version is set to VER_NDX_LOCAL due to `local: *`
* foo's version is set to V1
* handleDynamicList() is called
- foo.computeBinding() is STB_GLOBAL
- foo.includeInDynsym() is true
- foo.isPreemptible is set (correct)
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D64550
This makes it longer necessary to patch the version scripts for the
samba ports, to avoid "duplicate symbol 'pdb_search_init' in version
script" errors.
PR: 230602
MFC after: 3 days
3.4.1, which is still in the stable/10 branch.
It looks like clang 3.4.1 implements static_asserts by instantiating a
temporary static object, and if those are in an anonymous union, it
results in "error: anonymous union can only contain non-static data
members".
To work around this implementation limitation, move the static_asserts
in question out of the anonymous unions.
This should make building the latest stable/11 from stable/10 possible
again.
Reported by: Mike Tancsa <mike@sentex.net>
MFC after: 3 days
libunwind and openmp to the upstream release_80 branch r364487
(effectively, 8.0.1 rc3). The 8.0.1 release will most likely
have no further changes.
MFC after: 1 week
X-MFC-With: r349004
Clarify comments on helpers used by LFTR [NFC]
I'm slowly wrapping my head around this code, and am making comment
improvements where I can.
Pull in r360972 from upstream llvm trunk (by Philip Reames):
[LFTR] Factor out a helper function for readability purpose [NFC]
Pull in r360976 from upstream llvm trunk (by Philip Reames):
[IndVars] Don't reimplement Loop::isLoopInvariant [NFC]
Using dominance vs a set membership check is indistinguishable from a
compile time perspective, and the two queries return equivelent
results. Simplify code by using the existing function.
Pull in r360978 from upstream llvm trunk (by Philip Reames):
[LFTR] Strengthen assertions in genLoopLimit [NFCI]
Pull in r362292 from upstream llvm trunk (by Nikita Popov):
[IndVarSimplify] Fixup nowrap flags during LFTR (PR31181)
Fix for https://bugs.llvm.org/show_bug.cgi?id=31181 and partial fix
for LFTR poison handling issues in general.
When LFTR moves a condition from pre-inc to post-inc, it may now
depend on value that is poison due to nowrap flags. To avoid this, we
clear any nowrap flag that SCEV cannot prove for the post-inc addrec.
Additionally, LFTR may switch to a different IV that is dynamically
dead and as such may be arbitrarily poison. This patch will correct
nowrap flags in some but not all cases where this happens. This is
related to the adoption of IR nowrap flags for the pre-inc addrec.
(See some of the switch_to_different_iv tests, where flags are not
dropped or insufficiently dropped.)
Finally, there are likely similar issues with the handling of GEP
inbounds, but we don't have a test case for this yet.
Differential Revision: https://reviews.llvm.org/D60935
Pull in r362971 from upstream llvm trunk (by Philip Reames):
Prepare for multi-exit LFTR [NFC]
This change does the plumbing to wire an ExitingBB parameter through
the LFTR implementation, and reorganizes the code to work in terms of
a set of individual loop exits. Most of it is fairly obvious, but
there's one key complexity which makes it worthy of consideration.
The actual multi-exit LFTR patch is in D62625 for context.
Specifically, it turns out the existing code uses the backedge taken
count from before a IV is widened. Oddly, we can end up with a
different (more expensive, but semantically equivelent) BE count for
the loop when requerying after widening. For the nestedIV example
from elim-extend, we end up with the following BE counts:
BEFORE: (-2 + (-1 * %innercount) + %limit)
AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)
This is the only test in tree which seems sensitive to this
difference. The actual result of using the wider BETC on this example
is that we actually produce slightly better code. :)
In review, we decided to accept that test change. This patch is
structured to preserve the old behavior, but a separate change will
immediate follow with the behavior change. (I wanted it separate for
problem attribution purposes.)
Differential Revision: https://reviews.llvm.org/D62880
Pull in r362975 from upstream llvm trunk (by Philip Reames):
[LFTR] Use recomputed BE count
This was discussed as part of D62880. The basic thought is that
computing BE taken count after widening should produce (on average)
an equally good backedge taken count as the one before widening.
Since there's only one test in the suite which is impacted by this
change, and it's essentially equivelent codegen, that seems to be a
reasonable assertion. This change was separated from r362971 so that
if this turns out to be problematic, the triggering piece is obvious
and easily revertable.
For the nestedIV example from elim-extend.ll, we end up with the
following BE counts:
BEFORE: (-2 + (-1 * %innercount) + %limit)
AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)
Note that before is an i32 type, and the after is an i64. Truncating
the i64 produces the i32.
Pull in r362980 from upstream llvm trunk (by Philip Reames):
Factor out a helper function for readability and reuse in a future
patch [NFC]
Pull in r363613 from upstream llvm trunk (by Philip Reames):
Fix a bug w/inbounds invalidation in LFTR (recommit)
Recommit r363289 with a bug fix for crash identified in pr42279.
Issue was that a loop exit test does not have to be an icmp, leading
to a null dereference crash when new logic was exercised for that
case. Test case previously committed in r363601.
Original commit comment follows:
This contains fixes for two cases where we might invalidate inbounds
and leave it stale in the IR (a miscompile). Case 1 is when switching
to an IV with no dynamically live uses, and case 2 is when doing
pre-to-post conversion on the same pointer type IV.
The basic scheme used is to prove that using the given IV (pre or
post increment forms) would have to already trigger UB on the path to
the test we're modifying. As such, our potential UB triggering use
does not change the semantics of the original program.
As was pointed out in the review thread by Nikita, this is defending
against a separate issue from the hasConcreteDef case. This is about
poison, that's about undef. Unfortunately, the two are different, see
Nikita's comment for a fuller explanation, he explains it well.
(Note: I'm going to address Nikita's last style comment in a separate
commit just to minimize chance of subtle bugs being introduced due to
typos.)
Differential Revision: https://reviews.llvm.org/D62939
Pull in r363875 from upstream llvm trunk (by Philip Reames):
[LFTR] Rename variable to minimize confusion [NFC]
(Recommit of r363293 which was reverted when a dependent patch was.)
As pointed out by Nikita in D62625, BackedgeTakenCount is generally
used to refer to the backedge taken count of the loop. A conditional
backedge taken count - one which only applies if a particular exit is
taken - is called a ExitCount in SCEV code, so be consistent here.
Pull in r363877 from upstream llvm trunk (by Philip Reames):
[LFTR] Stylistic cleanup as suggested in last review comment of
D62939 [NFC]
(Resumbit of r363292 which was reverted along w/an earlier patch)
Pull in r364346 from upstream llvm trunk (by Philip Reames):
[LFTR] Adjust debug output to include extensions (if any)
Pull in r364693 from upstream llvm trunk (by Philip Reames):
[IndVars] Remove a bit of manual constant folding [NFC]
SCEV is more than capable of folding (add x, trunc(0)) to x.
Pull in r364709 from upstream llvm trunk (by Nikita Popov):
[LFTR] Fix post-inc pointer IV with truncated exit count (PR41998)
Fixes https://bugs.llvm.org/show_bug.cgi?id=41998. Usually when we
have a truncated exit count we'll truncate the IV when comparing
against the limit, in which case exit count overflow in post-inc form
doesn't matter. However, for pointer IVs we don't do that, so we have
to be careful about incrementing the IV in the wide type.
I'm fixing this by removing the IVCount variable (which was ExitCount
or ExitCount+1) and replacing it with a UsePostInc flag, and then
moving the actual limit adjustment to the individual cases (which
are: pointer IV where we add to the wide type, integer IV where we
add to the narrow type, and constant integer IV where we add to the
wide type).
Differential Revision: https://reviews.llvm.org/D63686
Together, these should fix a hang when building the textproc/htmldoc
port, due to an incorrect loop optimization.
PR: 237515
MFC after: 1 week
Summary:
Toolchain follow-up to r349350. LLVM patches will be submitted upstream for
9.0 as well.
The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it
cannot determine for certain that it needs Secure-PLT, and some binaries do
not compile in such a way to make it know to use Secure-PLT.
Reviewed By: nwhitehorn, bdragon, pfg
Differential Revision: https://reviews.freebsd.org/D20598
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.
MFC after: 2 weeks
[SelectionDAG] soften assertion when legalizing narrow vector FP ops
The test based on PR42010:
https://bugs.llvm.org/show_bug.cgi?id=42010
...may show an inaccuracy for PPC's target defs, but we should not be
so aggressive with an assert here. There's no telling what
out-of-tree targets look like.
This fixes an assertion when building the graphics/mesa-dri port for
PowerPC64.
Reported by: Mark Millard <marklmi26-fbsd@yahoo.com>
PR: 238082
MFC after: 3 days
[ARM] Glue register copies to tail calls.
This generally follows what other targets do. I don't completely
understand why the special case for tail calls existed in the first
place; even when the code was committed in r105413, call lowering
didn't work in the way described in the comments.
Stack protector lowering breaks if the register copies are not glued
to a tail call: we have to insert the stack protector check before
the tail call, and we choose the location based on the assumption
that all physical register dependencies of a tail call are adjacent
to the tail call. (See FindSplitPointForStackProtector.) This is sort
of fragile, but I don't see any reason to break that assumption.
I'm guessing nobody has seen this before just because it's hard to
convince the scheduler to actually schedule the code in a way that
breaks; even without the glue, the only computation that could
actually be scheduled after the register copies is the computation of
the call address, and the scheduler usually prefers to schedule that
before the copies anyway.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41417
Differential Revision: https://reviews.llvm.org/D60427
This should fix several instances of "Bad machine code: Using an
undefined physical register", when compiling ports such as
multimedia/vlc, audio/alsa-lib and devel/avro-c for armv6, with
-fstack-protector-strong.
Reported by: jbeich
PR: 237074, 237783, 237784
MFC after: 3 days
[objc-gnustep] Use .init_array not .ctors when requested.
This doesn't make a difference most of the time but FreeBSD/ARM
doesn't run anything in the .ctors array.
This should help with updating the libobjc2 port for armv7.
Requested by: theraven
Upstream PR: https://github.com/gnustep/libobjc2/issues/83
MFC after: 3 days
