| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Previously we had names like 'Call' or 'Tail'. This potentially clashes with
the naming scheme used elsewhere in RISCVInstrInfo.td. Many other backends
would use names like AArch64call or PPCtail. I prefer the SystemZ approach,
which uses prefixed all-lowercase names. This matches the naming scheme used
for target-independent SelectionDAG nodes.
llvm-svn: 351823
|
|
|
|
| |
llvm-svn: 351822
|
|
|
|
| |
llvm-svn: 351821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::is_trivially_copyable portability is verified at compile time using
std::is_trivially_copyable as the reference implementation.
Unfortunately, the latter is not available on all platforms, so introduce
a proper configure check to detect if it is available on the target platform.
In a similar manner, std::is_copy_assignable is not fully supported for gcc4.9.
Provide a portable (?) implementation instead.
Differential Revision: https://reviews.llvm.org/D57018
llvm-svn: 351820
|
|
|
|
|
|
|
|
|
|
| |
For constant bit select patterns, replace one AND with a ANDNP, allowing us to reuse the constant mask. Only do this if the mask has multiple uses (to avoid losing load folding) or if we have XOP as its VPCMOV can handle most folding commutations.
This also requires computeKnownBitsForTargetNode support for X86ISD::ANDNP and X86ISD::FOR to prevent regressions in fabs/fcopysign patterns.
Differential Revision: https://reviews.llvm.org/D55935
llvm-svn: 351819
|
|
|
|
| |
llvm-svn: 351818
|
|
|
|
|
|
|
|
| |
Similar to horizontal ops on D56777, the sse2 (but not mmx) bit shift ops has local forwarding disabled, adding +1cy to the use latency for the result.
Differential Revision: https://reviews.llvm.org/D57026
llvm-svn: 351817
|
|
|
|
| |
llvm-svn: 351816
|
|
|
|
|
|
|
|
| |
Similar to horizontal ops on D56777, the vpermilpd/vpermilps variable mask ops has local forwarding disabled, adding +1cy to the use latency for the result.
Differential Revision: https://reviews.llvm.org/D57022
llvm-svn: 351815
|
|
|
|
|
|
| |
Actually, just testing commits via monorepo ;)
llvm-svn: 351814
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D57042
llvm-svn: 351813
|
|
|
|
| |
llvm-svn: 351812
|
|
|
|
|
|
|
| |
This reverts commit r351801, as it caused errors on (so far)
ppc64be and aarch64 buildbots - the reason is yet unknown.
llvm-svn: 351811
|
|
|
|
|
|
|
|
| |
First step towards PR40376, this patch adds support for getCmpSelInstrCost to use the (optional) Instruction CmpInst predicate to indicate the type of integer comparison we're performing and alter the costs accordingly.
Differential Revision: https://reviews.llvm.org/D57013
llvm-svn: 351810
|
|
|
|
|
|
| |
The assertion is always true, and triggers a compiler warning, so remove it.
llvm-svn: 351809
|
|
|
|
|
|
|
|
|
|
|
| |
Change the top comment in PolyhedralInfo.cpp to use // instead of ///,
similarly to headers in other files. This fixes the issue of copyright
line exceeding textwidth and triggering polly-check-format45 failure,
e.g. seen here:
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd8/builds/18293/steps/run%20unit%20tests/logs/stdio
llvm-svn: 351808
|
|
|
|
|
|
|
|
| |
When we are inserting 1 "inline" element, and zeroing 2 of the other elements then we can safely commute the insertps source inputs to improve memory folding.
Differential Revision: https://reviews.llvm.org/D56843
llvm-svn: 351807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid the infinite loop caused by the target DAG combine converting ANYEXT to
SIGNEXT and the target-independent DAG combine logic converting back to
ANYEXT. Do this by not adding the new node to the worklist.
Committing directly as this definitely doesn't make the problem any worse, and
I intend to follow-up with a patch that avoids this custom combiner logic
altogether and just lowers the i32 operations to a target-specific
SelectionDAG node. This should be easier to reason about and improve codegen
quality in some cases (though may miss out on some later DAG combines).
llvm-svn: 351806
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support of guards expressed as branches by widenable
conditions in Loop Predication.
Differential Revision: https://reviews.llvm.org/D56081
Reviewed By: reames
llvm-svn: 351805
|
|
|
|
|
|
| |
Noticed in code coverage tests that this isn't tested.
llvm-svn: 351804
|
|
|
|
| |
llvm-svn: 351803
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57007
llvm-svn: 351801
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57006
llvm-svn: 351800
|
|
|
|
|
|
|
|
|
|
|
|
| |
make_error<StringError>
This was requested in the review of D57006.
Also add missing quotes around symbol names in error messages.
Differential Revision: https://reviews.llvm.org/D57014
llvm-svn: 351799
|
|
|
|
| |
llvm-svn: 351798
|
|
|
|
| |
llvm-svn: 351797
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This broke the RISCV build, and even with that fixed, one of the RISCV
tests behaves surprisingly differently with asserts than without,
leaving there no clear test pattern to use. Generally it seems bad for
hte IR to differ substantially due to asserts (as in, an alloca is used
with asserts that isn't needed without!) and nothing I did simply would
fix it so I'm reverting back to green.
This also required reverting the RISCV build fix in r351782.
llvm-svn: 351796
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes https://bugs.llvm.org/show_bug.cgi?id=40068.
--basenames is a GNU addr2line switch which strips the directory names
from the file path in the output.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D56919
llvm-svn: 351795
|
|
|
|
| |
llvm-svn: 351794
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ilya-biryukov, sammccall
Reviewed By: sammccall
Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D56860
llvm-svn: 351793
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds some basic supports for clang-tidy configurations in clangd:
- clangd will respect .clang-tidy configurations for each file
- we don't aim to support all clang-tidy options in clangd, only a
small subset of condfigurations (options related to which checks will be
enabled) are supported.
- add a `clang-tidy-checks` CLI option that can override options from
.clang-tidy file
Reviewers: ilya-biryukov, sammccall
Reviewed By: sammccall
Subscribers: javed.absar, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D55256
llvm-svn: 351792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a function to detect guards expressed in explicit control
flow form as branch by `and` with widenable condition intrinsic call:
%wc = call i1 @llvm.experimental.widenable.condition()
%guard_cond = and i1, %some_cond, %wc
br i1 %guard_cond, label %guarded, label %deopt
deopt:
<maybe some non-side-effecting instructions>
deoptimize()
This form can be used as alternative to implicit control flow guard
representation expressed by `experimental_guard` intrinsic.
Differential Revision: https://reviews.llvm.org/D56074
Reviewed By: reames
llvm-svn: 351791
|
|
|
|
|
|
|
|
|
|
|
| |
r351789 changes the output of llvm-readelf --dyn-symbols. This causes 3
LLD tests to break. This patch fixes them.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D56911
llvm-svn: 351790
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add new --hash-symbols switch for old behaviour
In r287786, the behaviour of --dyn-symbols in llvm-readelf (but not
llvm-readobj) was changed to print the dynamic symbols as derived from
the hash table, rather than to print the dynamic symbol table contents
directly. The original change was initially submitted without review,
and some comments were made on the commit mailing list implying that the
new behavious is GNU compatible. I argue that it is not:
1) It does not include a null symbol.
2) It prints the symbols based on an order derived from the hash
table.
3) It prints an extra column indicating which bucket it came from.
This could break parsers that expect a fixed number of columns,
with the first column being the symbol index.
4) If the input happens to have both .hash and .gnu.hash section, it
prints interpretations of them both, resulting in most symbols
being printed twice.
5) There is no way of just printing the raw dynamic symbol table,
because --symbols also prints the static symbol table.
This patch reverts the --dyn-symbols behaviour back to its old behaviour
of just printing the contents of the dynamic symbol table, similar to
what is printed by --symbols. As the hashed interpretation is still
desirable to validate the hash table, it puts it under a new switch
"--hash-symbols". This is a no-op on all output forms except for GNU
output style for ELF. If there is no hash table, it does nothing,
unlike the previous behaviour which printed the raw dynamic symbol
table, since the raw dynsym is available under --dyn-symbols.
The yaml input for the test is based on that in
test/tools/llvm-readobj/demangle.test, but stripped down to the bare
minimum to provide a valid dynamic symbol.
Note: some LLD tests needed updating. I will commit a separate patch for
those.
Reviewed by: grimar, rupprecht
Differential Revision: https://reviews.llvm.org/D56910
llvm-svn: 351789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
manipulations into OverlayCDB.
Summary:
Some projects make use of clang plugins when building, but clangd is
not aware of those plugins therefore can't work with the same compile command
arguments.
There were multiple places clangd performed commandline manipulations,
this one also moves them all into OverlayCDB.
Reviewers: ilya-biryukov
Subscribers: klimek, sammccall, ioeric, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D56841
llvm-svn: 351788
|
|
|
|
|
|
|
|
| |
Upgraded the bot as workaround.
This reverts commit r351784.
llvm-svn: 351786
|
|
|
|
|
|
|
| |
The break isn't strictly needed yet as there is no subsequent entry in the
case. But adding to prevent mistakes further down the road.
llvm-svn: 351785
|
|
|
|
|
|
| |
This fails to compile with clang ang libstdc++ 4.6
llvm-svn: 351784
|
|
|
|
|
|
| |
This function can be already intercepted by instrumented code.
llvm-svn: 351783
|
|
|
|
|
|
|
| |
Also add a comment to explain the expansion strategy for atomicrmw
{fadd,fsub}.
llvm-svn: 351782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch extends SymbolFileBreakpad::AddSymbols to include the symbols
from the FUNC records too. These symbols come from the debug info and
have a size associated with them, so they are given preference in case
there is a PUBLIC record for the same address.
To achieve this, I first pre-process the symbols into a temporary
DenseMap, and then insert the uniqued symbols into the module's symtab.
Reviewers: clayborg, lemo, zturner
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56590
llvm-svn: 351781
|
|
|
|
|
|
|
|
|
| |
The new LLVM header is one line shorter than the old one, which lead to
some test failures. Ideally tests should rely on line numbers for
breakpoints or output, but that's a different discussion. Hopefully this
turns the bots green again.
llvm-svn: 351779
|
|
|
|
|
|
| |
Add just fadd/fsub for now.
llvm-svn: 351778
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch may seem familiar... but my previous patch handled the
equivalent lsls+and, not this case. Usually instcombine puts the
"and" after the shift, so this case doesn't come up. However, if the
shift comes out of a GEP, it won't get canonicalized by instcombine,
and DAGCombine doesn't have an equivalent transform.
This also modifies isDesirableToCommuteWithShift to suppress DAGCombine
transforms which would make the overall code worse.
I'm not really happy adding a bunch of code to handle this, but it would
probably be tricky to substantially improve the behavior of DAGCombine
here.
Differential Revision: https://reviews.llvm.org/D56032
llvm-svn: 351776
|
|
|
|
|
|
|
|
| |
Deopt operands are generally intended to record information about a site in code with minimal perturbation of the surrounding code. Idiomatically, they also tend to appear down rare paths. Putting these together, we have an obvious case for extending CVP w/deopt operand constant folding. Arguably, we should be doing this for all operands on all instructions, but that's definitely a much larger and risky change.
Differential Revision: https://reviews.llvm.org/D55678
llvm-svn: 351774
|
|
|
|
| |
llvm-svn: 351773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, clarify the following:
1. Volatile load and store may access addresses that are not memory.
2. Volatile load and store do not modify arbitrary memory.
3. Volatile load and store do not trap.
Prompted by recent volatile discussion on llvmdev.
Currently, there's sort of a split in the source code about whether
volatile operations are allowed to trap; this resolves that dispute in
favor of not allowing them to trap.
Differential Revision: https://reviews.llvm.org/D53184
llvm-svn: 351772
|
|
|
|
| |
llvm-svn: 351771
|
|
|
|
| |
llvm-svn: 351770
|
|
|
|
| |
llvm-svn: 351769
|