| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
It seems like perhaps because cstdio isn't directly included, the
compiler is accidentally picking up wprintf from somewhere else
and trying to call that. Hopefully this fixes it.
llvm-svn: 338614
|
|
|
|
|
|
|
|
|
|
| |
'__builtin_ffs + 5'
We now emit a move of -1 before the cmov and do the addition after the cmov just like the case with an extra addition.
This may be slightly worse for code size, but is more consistent with other compilers. And we might be able to hoist the mov -1 outside of loops.
llvm-svn: 338613
|
|
|
|
|
|
| |
We previously had tests for "__builtin_ffs + 5", but the SelectinoDAG without an extra addition came out slightly different.
llvm-svn: 338612
|
|
|
|
|
|
|
| |
The previous documentation was just copied from PrintfAsRawHex8
but doesn't actually fit to the PutHex8 method.
llvm-svn: 338611
|
|
|
|
|
|
| |
Non ext aligned i32 loads are still optimized to use CONSTANT_BUFFER (AS 8)
llvm-svn: 338610
|
|
|
|
|
|
|
|
|
| |
This is useful for understanding how our demangler processes
back references and for investigating issues related to
back references. But it's a feature only useful for debugging
the demangling process itself, so I'm marking it hidden.
llvm-svn: 338609
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After we detected the presence of a template via ?$ we would proceed by
only demangling a simple unqualified name. This means we would fail on
templated operators (and perhaps other yet-to-be-determined things)
This was discovered while doing some refactoring to store richer
semantic information about the demangled types to pave the way for
overhauling the way we handle backreferences. (Specifically, we need to
defer recording or resolving back-references until a symbol has been
completely demangled, because we need to use information that only
occurs later in the mangled string to decide whether a back-reference
should be recorded.)
Differential Revision: https://reviews.llvm.org/D50145
llvm-svn: 338608
|
|
|
|
|
|
|
| |
We crash a lot on unrecognized inputs. This adds some error
handling so we early out when we get unrecognized names.
llvm-svn: 338607
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes: https://github.com/google/sanitizers/issues/966
Reviewers: kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D50131
llvm-svn: 338606
|
|
|
|
|
|
| |
There is no format parameter for any of these methods.
llvm-svn: 338605
|
|
|
|
| |
llvm-svn: 338604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Android's memory allocators also guarantee 8-byte alignment for 32-bit
architectures and 16-byte alignment for 64-bit.
Reviewers: rsmith
Subscribers: cfe-commits, srhines, enh
Differential Revision: https://reviews.llvm.org/D50112
llvm-svn: 338603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_memcpy and __builtin_memmove (in non-type-punning cases)."
It caused asserts during Chromium builds, see reply on the cfe-commits thread.
> This is intended to permit libc++ to make std::copy etc constexpr
> without sacrificing the optimization that uses memcpy on
> trivially-copyable types.
>
> __builtin_strcpy and __builtin_wcscpy are not handled by this change.
> They'd be straightforward to add, but we haven't encountered a need for
> them just yet.
llvm-svn: 338602
|
|
|
|
|
|
|
| |
This reverts commit r338596 because it contained a functional change.
The patch accidentally replaced StringRef::startswith with the exact match.
llvm-svn: 338600
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D25878, which added support for !absolute_symbol for normal X86 ISel,
did not add support for materializing references to absolute symbols for
X86 FastISel. This causes build failures because FastISel generates
PC-relative relocations for absolute symbols. Fall back to normal ISel
for references to !absolute_symbol GVs. Fix for PR38200.
Reviewers: pcc, craig.topper
Reviewed By: pcc
Subscribers: hiraditya, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D50116
llvm-svn: 338599
|
|
|
|
| |
llvm-svn: 338598
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compilationDatabaseChanges in the 'workspace/didChangeConfiguration' request
This commit allows clangd to use an in-memory compilation database that's
controlled from the LSP client (-compile_args_from=lsp). It extends the
'workspace/didChangeConfiguration' request to allow the client to pass in a
compilation database subset that needs to be updated in the workspace.
Differential Revision: https://reviews.llvm.org/D49758
llvm-svn: 338597
|
|
|
|
| |
llvm-svn: 338596
|
|
|
|
|
|
| |
I've put CMPXCHG8B/CMPXCHG16B in the same file, even though technically they are under separate CPUID bits all targets seem to support both (or neither).
llvm-svn: 338595
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, I thought that install-liblldb would fail because CMake had
a bug related to installing frameworks. In actuality, I misunderstood the
semantics of `add_custom_target`: the DEPENDS option refers to specific files,
not targets. Therefore `install-liblldb` should rely on the actual liblldb
getting generated rather than the target.
This means that the previous patch I committed (to stop relying on CMake's
framework support) is no longer needed and has been reverted. Using CMake's
framework support greatly simplifies the implementation.
`install-lldb-framework` (and the stripped variant) is as simple as
depending on `install-liblldb` because CMake knows that liblldb was built as a
framework and will install the whole framework for you. The stripped variant
will depend on the stripped variants of individual tools only to ensure they
actually are stripped as well.
Reviewers: labath, sas
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50038
llvm-svn: 338594
|
|
|
|
|
|
| |
This was fixed with rL338592.
llvm-svn: 338593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug is visible in the constant-folded x86 tests. We can't use the
negated shift amount when the type is not power-of-2:
https://rise4fun.com/Alive/US1r
...so in that case, use the regular lowering that includes a select
to guard against a shift-by-bitwidth. This path is improved by only
calculating the modulo shift amount once now.
Also, improve the rotate (with power-of-2 size) lowering to use
a negate rather than subtract from bitwidth. This improves the
codegen whether we have a rotate instruction or not (although
we can still see that we're not matching to a legal rotate in
all cases).
llvm-svn: 338592
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath
Reviewed By: labath
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D50025
llvm-svn: 338591
|
|
|
|
|
|
|
|
|
| |
Clarify how StackFrameList works by documenting its methods. Also,
delete some dead code and insert some TODOs.
Differential Revision: https://reviews.llvm.org/D50087
llvm-svn: 338590
|
|
|
|
|
|
|
| |
Using early returns in this function substantially reduces the nesting
level, making the logic easier to understand.
llvm-svn: 338589
|
|
|
|
|
|
|
|
| |
Splitting GetOnlyConcreteFramesUpTo will make it easier to implement
support for synthetic tail call frames in backtraces. This is just a
prep change, no functionality is affected.
llvm-svn: 338588
|
|
|
|
| |
llvm-svn: 338587
|
|
|
|
|
|
|
|
| |
There is nothing x86-specific about this code, so it'd be nice to make this available for other targets to use in the future (and get it out of X86ISelLowering!).
Differential Revision: https://reviews.llvm.org/D50083
llvm-svn: 338586
|
|
|
|
|
|
|
|
| |
This patch just extract code into a separate function to remove some
duplication between the old and new pass manager pipeline. Due to the
different CGSCC iterators used, not all code duplication was eliminated.
llvm-svn: 338585
|
|
|
|
|
|
| |
These aren't just available via 3DNow! so test for them separately as well.
llvm-svn: 338584
|
|
|
|
|
|
| |
Renamed the btver2 file that already contained them - the other targets were only testing the AVX versions
llvm-svn: 338583
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add support for --rename-section flags from gnu objcopy.
Not all flags appear to have an effect for ELF objects, but allowing them would allow easier drop-in replacement. Other unrecognized flags are rejected.
This was only tested by comparing flags printed by "readelf -e <.o>" against the output of gnu vs llvm objcopy, it hasn't been tested to be valid beyond that.
Reviewers: jakehehrlich, alexshap
Subscribers: llvm-commits, paulsemel, alexshap
Differential Revision: https://reviews.llvm.org/D49870
llvm-svn: 338582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The taskloop testcase had scheduling effects. Tasks of the taskloop would
sometimes be scheduled before all task were created. The testing is now
split into two phases. First, the task creation on the master is tested,
than the scheduling events of the tasks are tested. Thus, the order of
creation and scheduling events is irrelavant.
Patch by Simon Convent
Reviewed by: protze.joachim, Hahnfeld
Subscribers: openmp-commits
Differential Revision: https://reviews.llvm.org/D50140
llvm-svn: 338580
|
|
|
|
|
|
| |
Found by inspection.
llvm-svn: 338579
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Bug was caused due to comments at the start of scope. For a code like:
```
int func() { //
int b;
int c;
}
```
the comment at the first line gets IndentAndNestingLevel (1,1) whereas
the following declarations get only (0,1) which prevents them from insertion
of a new scope. So, I changed the AlignTokenSequence to look at previous
*non-comment* token when deciding whether to introduce a new scope into
stack or not.
Patch by Kadir Cetinkaya!
Reviewers: rsmith, djasper
Reviewed By: djasper
Subscribers: lebedev.ri, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43303
llvm-svn: 338578
|
|
|
|
| |
llvm-svn: 338577
|
|
|
|
| |
llvm-svn: 338576
|
|
|
|
| |
llvm-svn: 338570
|
|
|
|
|
|
|
|
| |
This was accidentally removed in r335942.
Differential Revision: https://reviews.llvm.org/D49934
llvm-svn: 338569
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang support for the Armv8.2-A FP16 vector intrinsic was committed in
rC328277, but this was never followed up, i.e. the LLVM part is missing.
I've raised PR38404, and this is the first step to address this. I.e.,
this adds tests for the Armv8.2-A FP16 vector intrinsic, and thus shows
which intrinsics already work, and which need further work.
Differential Revision: https://reviews.llvm.org/D50142
llvm-svn: 338568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
And implement memory instructions on X86.
This fixes PR36906.
Reviewers: gchatelet
Reviewed By: gchatelet
Subscribers: lebedev.ri, filcab, mgorny, tschuett, RKSimon, llvm-commits
Differential Revision: https://reviews.llvm.org/D48935
llvm-svn: 338567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the unroll_and_jam pragma, to go with the recently
added unroll and jam pass. The name of the pragma is the same as is used
in the Intel compiler, and most of the code works the same as for unroll.
#pragma clang loop unroll_and_jam has been separated into a different
patch. This part adds #pragma unroll_and_jam with an optional count, and
#pragma no_unroll_and_jam to disable the transform.
Differential Revision: https://reviews.llvm.org/D47267
llvm-svn: 338566
|
|
|
|
|
|
| |
We already added these to btver2, now add them to other targets, even though none of their models treat them specially (yet).
llvm-svn: 338565
|
|
|
|
| |
llvm-svn: 338564
|
|
|
|
|
|
| |
CPUID, IN/OUT, INS/OUTS, INT, PAUSE, SCAS, UD2, XLAT
llvm-svn: 338563
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49806
llvm-svn: 338562
|
|
|
|
| |
llvm-svn: 338561
|
|
|
|
| |
llvm-svn: 338560
|
|
|
|
| |
llvm-svn: 338559
|
|
|
|
| |
llvm-svn: 338558
|