| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug:
https://bugs.llvm.org/show_bug.cgi?id=37648
...was created with the enhancement to this transform with rL332479.
The urem test shows the disaster potential: any undef divisor lane makes
the whole op undef.
The test diffs show that vector demanded elements turns some of the potential,
but not all, unused binop operands back into undef already.
llvm-svn: 333782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Occasionally, when launching a process in lldb (especially on windows, but not limited to), lldb will hang before the process is launched and it will never recover. This happens because the timing of the processing of the state changes can be slightly different. The state changes that are issued are:
1) SetPublicState(eStateLaunching)
2) SetPrivateState(eStateLaunching)
3) SetPublicState(eStateStopped)
4) SetPrivateState(eStateStopped)
What we expect to see is:
public state: launching -> launching -> stopped
private state: launching -> stopped
What we see is:
public state: launching -> stopped -> launching
private state: launching -> stopped
The second launching change to the public state is issued when WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was created when the private state was set to launching. HandlePrivateEvent has logic to determine whether to broadcase the event and a launching event is *always* broadcast. At the same time, when the stopped event is processed by WaitForProcessStopPrivate next, the function exists and that event is never broadcast, so the public state remains as launching.
HandlePrivateEvent does two things: determine whether there's a next action as well as determine whether to broadcast the event that was processed. There's only ever a next action set if we are trying to attach to a process, but WaitForProcessStopPrivate is only ever called when we are launching a process or connecting remotely, so the first part of HandlePrivateEvent (handling the next action) is irrelevant for WaitForProcessStopPrivate. As far as broadcasting the event is concerned, since we are handling state changes that already occurred to the public state (and are now duplicated in the private state), I believe the broadcast step is unnecessary also (and in fact, it causes the hang).
This change removes the call to HandlePrivateEvent from inside WaitForProcessStopPrivate.
Incidentally, there was also a bug filed recently that is the same issue: https://bugs.llvm.org/show_bug.cgi?id=37496
Reviewers: asmith, labath, zturner, jingham
Reviewed By: zturner, jingham
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47609
llvm-svn: 333781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: partitionSetParts from C to new C++ interface.
Reviewers: grosser, Meinersbur, jdoerfert, bollu, cs15btech11044
Reviewed By: grosser, Meinersbur
Subscribers: llvm-commits, pollydev
Tags: #polly
Differential Revision: https://reviews.llvm.org/D47252
llvm-svn: 333780
|
|
|
|
| |
llvm-svn: 333779
|
|
|
|
|
|
|
|
|
|
| |
around their __builtin function with appropriate arguments rather than just passing arguments to the masked intrinsic.
This is more consistent with all of our other avx512 macro intrinsics.
It also fixes a bad cast where an argument was casted to mmask8 when it should have been a mmask16.
llvm-svn: 333778
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The LLDB.framework generated when building with CMake + Ninja/Make is
completely missing the clang headers. Although the code to copy them exists, we
don't even generate them unless we're building LLDB standalone.
Reviewers: clayborg, labath, sas
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47612
llvm-svn: 333777
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part).
This patch fixes the libc++ version of the __c11_atomic_load builtins defined for GCC's compatibility sake.
D47618 takes care of the clang side.
Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html
<rdar://problem/27426936>
Reviewers: EricWF, mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47613
llvm-svn: 333776
|
|
|
|
|
|
|
| |
This should address a bot failure:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/9994/
llvm-svn: 333775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `MipsAsmParser::loadImmediate` can load immediates of various sizes
into a register. Idea of this change is to use `loadImmediate` in the
`MipsAsmParser::expandMemInst` method to load offset into a register and
then call required load/store instruction.
The patch removes separate `expandLoadInst` and `expandStoreInst`
methods and does everything in the `expandMemInst` method to escape code
duplication.
Differential Revision: https://reviews.llvm.org/D47316
llvm-svn: 333774
|
|
|
|
|
|
|
| |
Supporting GOT and TLS related relocations by the `.reloc` directive is
useful for purpose of testing various tools like a linker, for example.
llvm-svn: 333773
|
|
|
|
|
|
|
|
|
| |
This fixes the bug where strip-all option was
leading to a malformed outputted ELF file.
Differential Revision: https://reviews.llvm.org/D47414
llvm-svn: 333772
|
|
|
|
| |
llvm-svn: 333771
|
|
|
|
| |
llvm-svn: 333770
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the relocations needed support the initial-exec TLS model:
R_PPC64_GOT_TPREL16_HA
R_PPC64_GOT_TPREL16_LO_DS
R_PPC64_GOT_TPREL16_DS
R_PPC64_GOT_TPREL16_HI
R_PPC64_TLS
Differential Revision: https://reviews.llvm.org/D47455
llvm-svn: 333769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Emit summaries for bitcode modules that are only destined for the
regular LTO portion of the build so they can participate in
summary-based dead stripping.
This change reduces the size of a nacl_helper build with cfi-icall
enabled by 7%, removing the majority of the overhead due to enabling
cfi-icall. The cfi-icall size increase was caused by compiling in lots
of unused code and cfi-icall generating jumptable references to unused
symbols that could no longer be removed by -Wl,-gc-sections. Increasing
the visibility of summary-based dead stripping prevented jumptable
entries being created for unused symbols from the regular LTO portion
of the build.
Reviewers: pcc
Reviewed By: pcc
Subscribers: dschuff, mehdi_amini, inglorion, eraman, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D47594
llvm-svn: 333768
|
|
|
|
| |
llvm-svn: 333767
|
|
|
|
| |
llvm-svn: 333766
|
|
|
|
| |
llvm-svn: 333765
|
|
|
|
|
|
| |
Candidate check precludes this check.
llvm-svn: 333764
|
|
|
|
|
|
| |
Do not consider store sizes large than the maximum legal store size.
llvm-svn: 333763
|
|
|
|
|
|
| |
r333423)
llvm-svn: 333762
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-no-canonical-prefixes is a weird flag: In gcc, it controls whether realpath()
is called on the path of the driver binary. It's needed to support some
usecases where gcc is symlinked to, see
https://gcc.gnu.org/ml/gcc/2011-01/msg00429.html for some background.
In clang, the resource dir is found relative to the compiler binary, and
without -no-canonical-prefixes that's an absolute path. For clang, the main use
case for -no-canonical-prefixes is to make the -resource-dir path added by the
driver relative instead of absolute. Making it relative seems like the better
default, but since neither clang not gcc have -canonical-prefixes without no-
which makes changing the default tricky, and since some symlink behaviors do
depend on the realpath() call at least for gcc, just expose
-no-canonical-prefixes in clang-cl mode.
Alternatively we could default to no-canonical-prefix-mode for clang-cl since
it's less likely to be used in symlinked scenarios, but since you already need
to about -no-canonical-prefixes for the non-clang-cl bits of your build, not
hooking this of driver mode seems better to me.
https://reviews.llvm.org/D47480
llvm-svn: 333761
|
|
|
|
| |
llvm-svn: 333760
|
|
|
|
| |
llvm-svn: 333759
|
|
|
|
|
|
|
| |
Also fix the return value of IdleASTs::getUsedBytes().
It was 'bool' instead of 'size_t' *facepalm*.
llvm-svn: 333758
|
|
|
|
|
|
|
| |
Clang calls "nvlink" for linking multiple object files with OpenMP
target functions, so correct this information when printing errors.
llvm-svn: 333757
|
|
|
|
| |
llvm-svn: 333756
|
|
|
|
|
|
|
| |
This will allow us to share the logic that computes the block throughput with
other views.
llvm-svn: 333755
|
|
|
|
|
|
| |
This patch makes local variables zero initialized to avoid broken values in debug output.
llvm-svn: 333754
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Screenshot in phabricator diff.
Reviewers: gchatelet
Subscribers: mgorny, tschuett, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D47329
llvm-svn: 333753
|
|
|
|
| |
llvm-svn: 333752
|
|
|
|
|
|
|
|
|
| |
Additionally, implement handling of ADD/SUBCARRY on Hexagon, utilizing
the UADDO/USUBO expansion.
Differential Revision: https://reviews.llvm.org/D47559
llvm-svn: 333751
|
|
|
|
| |
llvm-svn: 333750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CHECK duplication (PR35003)
This patch replaces the --x86_extra_scrub command line argument to automatically support a second level of regex-scrubbing if it improves the matching of nearly-identical code patterns. The argument '--extra_scrub' is there now to force extra matching if required.
This is mostly useful to help us share 32-bit/64-bit x86 vector tests which only differs by retl/retq instructions, but any scrubber can now technically support this, meaning test checks don't have to be needlessly obfuscated.
I've updated some of the existing checks that had been manually run with --x86_extra_scrub, to demonstrate the extra "ret{{[l|q]}}" scrub now only happens when useful, and re-run the sse42-intrinsics file to show extra matches - most sse/avx intrinsics files should be able to now share 32/64 checks.
Tested with the opt/analysis scripts as well which share common code - AFAICT the other update scripts use their own versions.
Differential Revision: https://reviews.llvm.org/D47485
llvm-svn: 333749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
They've been deprecated in favor of UADDO/ADDCARRY or USUBO/SUBCARRY for a while.
Target that uses these opcodes are changed in order to ensure their behavior doesn't change.
Reviewers: efriedma, craig.topper, dblaikie, bkramer
Subscribers: jholewinski, arsenm, jyknight, sdardis, nemanjai, nhaehnle, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, llvm-commits
Differential Revision: https://reviews.llvm.org/D47422
llvm-svn: 333748
|
|
|
|
|
|
|
|
|
|
|
| |
Before we were relying on the any extend of the s1 to s32, but
for AAPCS we need to zero-extend it to at least s8.
Fixes PR36719
Differential Revision: https://reviews.llvm.org/D47425
llvm-svn: 333747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compiler crashes when omp simd is used in an OpenCL file:
clang -c -fopenmp omp_simd.cl
__kernel void test(global int *data, int size) {
#pragma omp simd
for (int i = 0; i < size; ++i) {
}
}
The problem seems to be the check added to verify block pointers have
initializers. An OMPCapturedExprDecl is created to capture ‘size’ but there is
no TypeSourceInfo.
The change just uses getType() directly.
Patch-By: mikerice
Differential Revision: https://reviews.llvm.org/D46667
llvm-svn: 333746
|
|
|
|
|
|
| |
This is breaking the clang-with-thin-lto-ubuntu bot.
llvm-svn: 333745
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unpredicated copy of floating-point immediate value into SVE vector,
along with MOV-aliases.
Reviewers: rengolin, fhahn, samparker, SjoerdMeijer, javed.absar
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D47482
llvm-svn: 333744
|
|
|
|
| |
llvm-svn: 333743
|
|
|
|
| |
llvm-svn: 333742
|
|
|
|
|
|
| |
Also, duplicate an alias for microMIPS.
llvm-svn: 333741
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
This patch updates IPSCCP to use PredicateInfo to propagate
facts to true branches predicated by EQ and to false branches
predicated by NE.
As a follow up, we should be able to extend it to also propagate additional
facts about nonnull.
Reviewers: davide, mssimpso, dberlin, efriedma
Reviewed By: davide, dberlin
Differential Revision: https://reviews.llvm.org/D45330
llvm-svn: 333740
|
|
|
|
|
|
|
|
| |
Reviewers: smaksimovic, atanasyan, abeserminji
Differential Revision: https://reviews.llvm.org/D47583
llvm-svn: 333739
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
index
Summary:
Back when we were introducing the DWARF v5 name index, there was a
short discussion whether we shouldn't have a nicer api for iterating
over the index. At that time, I did not find it necessary since the
iteration over names was done only from within the index itself (and I
figured the internal implementation can deal with a slightly rough
interface).
However, now I ran into a use for this kind of API in LLDB (for finding
all names matching a regular expression), so it looked like a nice
opportunity to introduce one. To make the API more useful, I've made the
NameTableEntry class a bit smarter: it now stores the string section
reference (so it can return its name) and its position in the name index
(mainly useful for dumping/logging).
I also convert the internal users to use the new API, which also gives
test coverage for the added code.
Reviewers: JDevlieghere, aprantl, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47590
llvm-svn: 333738
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After this commit, clangd will only keep the last 3 accessed ASTs in
memory. Preambles for each of the opened files are still kept in
memory to make completion and AST rebuilds fast.
AST rebuilds are usually fast enough, but having the last ASTs in
memory still considerably improves latency of operations like
findDefinition and documeneHighlight, which are often sent multiple
times a second when moving around the code. So keeping some of the last
accessed ASTs in memory seems like a reasonable tradeoff.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: malaperle, arphaman, klimek, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47063
llvm-svn: 333737
|
|
|
|
|
|
|
|
| |
Reviewers: smaksimovic, atanasyan, abeserminji
Differential Revision: https://reviews.llvm.org/D47582
llvm-svn: 333736
|
|
|
|
|
|
|
|
|
| |
From a follow-up discussion in D44480.
New tests check that function bodies are not skipped:
- In presence of ptr declarators, e.g. `auto**`.
- When `decltype(auto)` is used in return type, only `auto` was checked before.
llvm-svn: 333735
|
|
|
|
|
|
|
| |
This was missed in a few places in SVN r333613, causing compilation
errors if these macros are used e.g. as parameter to a function.
llvm-svn: 333734
|
|
|
|
|
|
|
|
|
|
|
|
| |
One test was marked as XFAIL for FreeBSD however still running when launching make check-xray
Reviewers: krytarowski, vitalybuka
Reviewed By: dberris
Differential Revision: https://reviews.llvm.org/D47622
llvm-svn: 333733
|