| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 351426
|
|
|
|
| |
llvm-svn: 351425
|
|
|
|
|
|
|
|
|
| |
Allow varargs functions to be called, both in arm and thumb mode. This
boils down to choosing the correct calling convention, which we can
easily test by making sure arm_aapcscc is used instead of
arm_aapcs_vfpcc when the callee is variadic.
llvm-svn: 351424
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is the missing bit to drive thread and memory sanitizers through clang using the new PassManager.
Reviewers: chandlerc, fedor.sergeev, vitalybuka, leonardchan
Subscribers: bollu, llvm-commits
Differential Revision: https://reviews.llvm.org/D56831
llvm-svn: 351423
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to support codegen RV64A, this patch:
* Introduces masked atomics intrinsics for atomicrmw operations and cmpxchg
that use the i64 type. These are ultimately lowered to masked operations
using lr.w/sc.w, but we need to use these alternate intrinsics for RV64
because i32 is not legal
* Modifies RISCVExpandPseudoInsts.cpp to handle PseudoAtomicLoadNand64 and
PseudoCmpXchg64
* Modifies the AtomicExpandPass hooks in RISCVTargetLowering to sext/trunc as
needed for RV64 and to select the i64 intrinsic IDs when necessary
* Adds appropriate patterns to RISCVInstrInfoA.td
* Updates test/CodeGen/RISCV/atomic-*.ll to show RV64A support
This ends up being a fairly mechanical change, as the logic for RV32A is
effectively reused.
Differential Revision: https://reviews.llvm.org/D53233
llvm-svn: 351422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are cases where we have multiple epilogues that have the exact same unwind
code sequence. In that case, the epilogues can share the same unwind codes in
the .xdata section. This should get us past the assert "SEH unwind data
splitting not yet implemented" in many cases.
We still need to add support for generating multiple .pdata/.xdata sections for
those functions that need to be split into fragments.
Differential Revision: https://reviews.llvm.org/D56813
llvm-svn: 351421
|
|
|
|
|
|
| |
Forgot to address this one.
llvm-svn: 351418
|
|
|
|
|
|
|
|
|
|
| |
This refactors the getRelocationValueString method.
It is a bit overcomplicated and it is possible to reduce it without
losing the functionality it seems.
Differential revision: https://reviews.llvm.org/D56778
llvm-svn: 351417
|
|
|
|
| |
llvm-svn: 351416
|
|
|
|
|
|
|
|
| |
This made the toolchain build 50% slower.
Differential Revision: https://reviews.llvm.org/D56825
llvm-svn: 351415
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Samuel Thibault
The GNU/Hurd system does not define an arbitrary PATH_MAX limitation, the POSIX 2001 realpath
extension can be used instead, and the size of symlinks can be determined.
Reviewed as https://reviews.llvm.org/D54677
llvm-svn: 351414
|
|
|
|
| |
llvm-svn: 351413
|
|
|
|
| |
llvm-svn: 351412
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function merging pass miscompiles identical vararg functions. The
forwarding thunk it emits doesn't forward the full variable-length list
of arguments. Disable merging for vararg functions for now.
I've filed llvm.org/PR40345 to track the issue.
rdar://47326238
llvm-svn: 351411
|
|
|
|
|
|
| |
This reverts commit eccdbba3a02a33e13b5262e92200a33e2ead873d.
llvm-svn: 351410
|
|
|
|
|
|
|
| |
This reverts commit 71eaf61c6c121c8c3bcaf3490557e92cf81599cb. One of
the lld tests was breaking, so revert this change until it is fixed.
llvm-svn: 351409
|
|
|
|
|
|
| |
scalar integer to vXi1 for the mask arguments to the intrinsics.
llvm-svn: 351408
|
|
|
|
|
|
|
|
| |
scalar integers for mask.
We will custom emit these builtins in clang using the new intrinsics that take a vXi1 mask.
llvm-svn: 351407
|
|
|
|
| |
llvm-svn: 351406
|
|
|
|
|
|
|
|
|
|
|
| |
Essentially, do not treat `call` and `musttail call` as the same thing.
As a drive-by, fold CallInst and InvokeInst handling together using the
CallSite helper.
Differential Revision: https://reviews.llvm.org/D56815
llvm-svn: 351405
|
|
|
|
|
|
|
| |
The Windows ARM64 runtime passes the establisher frame to funclets as the first
argument.
llvm-svn: 351404
|
|
|
|
|
|
| |
Also, fix a few existing links so they don't require registration.
llvm-svn: 351403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes `-emit-header-module` when GenerateHeaderModuleAction is wrapped
by another frontend action.
rdar://problem/47302588
Reviewers: rsmith, arphaman
Reviewed By: arphaman
Subscribers: jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D56766
llvm-svn: 351402
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: sbc100, aheejin, dschuff
Subscribers: jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D56807
llvm-svn: 351400
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Everything before the word "version" is the tool, and everything after
the word "version" is the version.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D56742
llvm-svn: 351399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
up-to-date.
Summary:
This replaces the sanitizer tool list (used for generating
sanitizer_common configurations) with a tool list derived from
existing build system information.
Previously sanitizer_common had its own list of supported sanitizer
tools. This was bad because it was out of sync with the rest of the
build system. Notably it meant that the sanitizer_common runtime was
only being tested on Darwin the ASan dylib and not the other sanitizer
dylibs that are built for Darwin (LSan, TSan, and UBSan).
Unfortunately enabling the tests against other sanitizer dylibs has lead
to some test failures on Darwin. For now they've been marked as
XFAIL until the failures can investigated properly.
For Windows and Android we use the old sanitizer tool list to try avoid
bot breakages.
rdar://problem/47143078
Reviewers: kubamracek, george.karpenkov, yln, samsonov, vitalybuka, krytarowski
Subscribers: srhines, mgorny, fedor.sergeev, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D55740
llvm-svn: 351398
|
|
|
|
|
|
| |
PGOInstrGen should be initialized to "" instead of false.
llvm-svn: 351397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LD -> LE optimization for Thread-Local Storage without PLT requires
an additional "66" prefix, otherwise the next instruction will be
corrupted, causing runtime misbehavior (crashes) of the linked object.
The other (GD -> IE/LD) optimizations are the same with or without PLT,
but add tests for completeness. The instructions are copied from
https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf#subsection.11.1.2
This does not try to address ILP32 (x32) support.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37303
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D56779
llvm-svn: 351396
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we do not always collapse subsequent .loc 0 0 directives. The
reason is that we were checking for a PrevInstLoc which is not set when
we emit a line-0 record. We should only check the LastAsmLine, which
seems to be created exactly for this purpose.
// When we emit a line-0 record, we don't update PrevInstLoc; so look at
// the last line number actually emitted, to see if it was line 0.
unsigned LastAsmLine =
Asm->OutStreamer->getContext().getCurrentDwarfLoc().getLine();
Differential revision: https://reviews.llvm.org/D56767
llvm-svn: 351395
|
|
|
|
|
|
|
|
|
| |
This is not NFC strictly speaking, since it unifies CleanupAttr handling,
so that out parameters now also understand it.
Differential Revision: https://reviews.llvm.org/D56759
llvm-svn: 351394
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D56744
llvm-svn: 351393
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we have pgo options defined in PassManagerBuilder.cpp only for
instrument pgo, but not for sample pgo. We also have pgo options defined
in NewPMDriver.cpp in opt only for new pass manager and for all kinds of
pgo. They have some inconsistency.
To make the options more consistent and make tests writing easier, the
patch let old pass manager to share the same pgo options with new pass
manager in opt, and removes the options in PassManagerBuilder.cpp.
Differential Revision: https://reviews.llvm.org/D56749
llvm-svn: 351392
|
|
|
|
|
|
| |
V8 has been fixed now.
llvm-svn: 351391
|
|
|
|
|
|
|
|
|
|
| |
vXi1 vector instead of a scalar
We need to custom handle these so we can turn the scalar mask into a vXi1 vector.
Differential Revision: https://reviews.llvm.org/D56530
llvm-svn: 351390
|
|
|
|
|
|
| |
custom handling in clang.
llvm-svn: 351389
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D56809
llvm-svn: 351388
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change factors out compiler checking / warning, and documents LLVM_FORCE_USE_OLD_TOOLCHAIN. It doesn't introduce any functional changes nor policy changes, these will come late.
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D56799
llvm-svn: 351387
|
|
|
|
| |
llvm-svn: 351386
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/677/steps/test/logs/stdio
llvm-svn: 351385
|
|
|
|
| |
llvm-svn: 351384
|
|
|
|
|
|
|
| |
There is a substitution for 'clang-check' to absolutize it, so the
'$(which clang-check)' is unnecessary.
llvm-svn: 351383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
member enum and then its enclosing class.
There are situations where ADL will collect a class but not the complete
set of associated classes / namespaces of that class. When that
happened, and we later tried to collect those associated classes /
namespaces, we would previously short-circuit the lookup and not find
them. Eg, for:
struct A : B { enum E; };
if we first looked for associated classes/namespaces of A::E, we'd find
only A. But if we then tried to also collect associated
classes/namespaces of A (which should include the base class B), we
would not add B because we had already visited A.
This also fixes a minor issue where we would fail to collect associated
classes from an overloaded class member access expression naming a
static member function.
llvm-svn: 351382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we used ISD::SHL and ISD::SRL to represent these in SelectionDAG. ISD::SHL/SRL interpret an out of range shift amount as undefined behavior and will constant fold to undef. While the intrinsics are defined to return 0 for out of range shift amounts. A previous patch added a special node for VPSRAV to produce all sign bits.
This was previously believed safe because undefs frequently get turned into 0 either from the constant pool or a desire to not have a false register dependency. But undef is treated specially in some optimizations. For example, its ignored in detection of vector splats. So if the ISD::SHL/SRL can be constant folded and all of the elements with in bounds shift amounts are the same, we might fold it to single element broadcast from the constant pool. This would not put 0s in the elements with out of bounds shift amounts.
We do have an existing InstCombine optimization to use shl/lshr when the shift amounts are all constant and in bounds. That should prevent some loss of constant folding from this change.
Patch by zhutianyang and Craig Topper
Differential Revision: https://reviews.llvm.org/D56695
llvm-svn: 351381
|
|
|
|
|
|
|
|
|
|
|
|
| |
just before isel table lookup. Remove vselect isel patterns.
This cleans up the duplication we have with both intrinsic isel patterns and vselect isel patterns. This should also allow the intrinsics to get SimplifyDemandedBits support for the condition.
I've switched the canonical pattern in isel to use the X86ISD::BLENDV node instead of VSELECT. Since it always seemed weird to move from BLENDV with its relaxed rules on condition bits to VSELECT which has strict rules about all bits of the condition element being the same. Its more correct to go from VSELECT to BLENDV.
Differential Revision: https://reviews.llvm.org/D56771
llvm-svn: 351380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For these loads that write to the HI part of a register, we should chain them to the op that writes to the LO part
of the register to maintain the appropriate order.
Reviewers:
rampitec, arsenm
Differential Revision:
https://reviews.llvm.org/D56454
llvm-svn: 351379
|
|
|
|
|
|
|
|
|
|
| |
combineVSelectWithAllOnesOrZeros
If we're going to generate a new inverted setcc, we should make sure we will be able to remove the old setcc.
Differential Revision: https://reviews.llvm.org/D56765
llvm-svn: 351378
|
|
|
|
| |
llvm-svn: 351377
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
|
|
|
|
|
|
|
| |
Additional tests for vNi32 and vNi64. I've added these for
usub.sat before, this covers uadd.sat, ssub.sat and sadd.sat.
llvm-svn: 351375
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lots of tests rely on llvm-lto being present, but LLVM_ENABLE_PIC=OFF currently
disables building that executable.
There's no reason for not building llvm-lto with LLVM_ENABLE_PIC=OFF so just
build it. r191042 moved it into a "if (!WIN)" block at the time, and then
211852 made that "if(NOT CYGWIN AND LLVM_ENABLE_PIC)" -- but that's only needed
for LTO (the ld64 plugin), not for the llvm-lto binary.
Differential Revision: https://reviews.llvm.org/D56801
llvm-svn: 351374
|