Precedence was wrong in an assert added in r364961. Add braces around the
assertion condition to make it right.
See: https://reviews.llvm.org/D64084
llvm-svn: 365069
The motivation for this is two fold:
1) Make the output (and thus tests) a bit more readable to a human trying to understand the result of the transform
2) Reduce spurious diffs in a potential future change to restructure all of this logic to use SCEVExpander (which hoists by default)
llvm-svn: 365066
Warnings can be promoted to errors.
But that shouldn't prevent us from getting the dependencies!
Differential Revision: https://reviews.llvm.org/D64149
llvm-svn: 365065
Instead of just stopping to see if we have a G_CONSTANT, instead, look through
G_TRUNCs, G_SEXTs, and G_ZEXTs.
This gives an average ~1.3% code size improvement on CINT2000 at -O3.
Differential Revision: https://reviews.llvm.org/D64108
llvm-svn: 365063
This patch generalizes the fix in D61680 to ignore all meta instructions,
not just debug info.
Patch by Chris Dawson.
Differential Revision: https://reviews.llvm.org/D62605
llvm-svn: 365061
This patch adjusts tests not to depend on deprecated FileCheck
behavior that permits overlapping matches within a block of
`CHECK-DAG` directives:
1. `thinlto-function-summary-originalnames.ll`: The directive with the
pattern `<COMBINED` is surely intended to match `<COMBINED ` (note the
trailing space), but it instead matches
`<COMBINED_GLOBALVAR_INIT_REFS`, for which there is a separate
directive. With the deprecated behavior, both directives match the
latter text and neither match the former text. I've adjusted the
former directive so it matches only the former text.
2. `thinlto-summary-local-5.0.ll`: Two directives have identical
patterns when they were clearly meant to have different patterns.
3. `upgrade-pointer-address-space.ll`: There are three identical
directives but only two occurrences of the matching text. With the
deprecated behavior, they always match exactly the same text, so the
behavior can't have been useful. I removed one of the directives and
converted the other two from `CHECK-DAG` to `CHECK`.
Reviewed By: probinson, aprantl
Differential Revision: https://reviews.llvm.org/D64036
llvm-svn: 365060
Summary:
This option allow the toggling of the libraries-svr4 usage in ProcessGDBRemote. It's a follow up of https://reviews.llvm.org/D62503#1564296 and it's meant to test / tweak this new packet with, hopefully, minimum impact and in a faster way.
Enable it with `settings set plugin.process.gdb-remote.use-libraries-svr4 true`. For now, by default it's false.
I didn't put tests up for this but I did test it manually.
Reviewers: labath, jankratochvil
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64112
llvm-svn: 365059
We previously marked all the tests with branch funnels as
`-verify-machineinstrs=0`.
This is an attempt to fix it.
1) `ICALL_BRANCH_FUNNEL` has no defs. Mark it as `let OutOperandList =
(outs)`
2) After that we hit an assert: ``` Assertion failed: (Op.getValueType()
!= MVT::Other && Op.getValueType() != MVT::Glue && "Chain and glue
operands should occur at end of operand list!"), function AddOperand,
file
/Users/francisvm/llvm/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp,
line 461. ```
The chain operand was added at the beginning of the operand list. Move
that to the end.
3) After that we hit another verifier issue in the pseudo expansion
where the registers used in the cmps and jmps are not added to the
livein lists. Add the `EFLAGS` to all the new MBBs that we create.
PR39436
Differential Review: https://reviews.llvm.org/D54155
llvm-svn: 365058
We haven't changed the set of users, just specialized an operand for those users. Given that, the previous wrap flags must still be correct.
Sorry for the lack of test case. Noticed this while working on something else, and haven't figured out to exercise this standalone.
llvm-svn: 365053
Summary:
Some clang versions (< 6.0) do not inline the atomic builtin functions
leaving unresolved references to `__atomic_load_8` and so on (seems to
be mostly 64-bit atomics on 32-bit platforms).
I tried without success to use some cmake magic to detect when that
would be the case, and decided to fall back to unconditionally
linking libatomic.
Reviewers: morehouse, eugenis, vitalybuka, hctim, tejohnson
Reviewed By: tejohnson
Subscribers: mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D64134
llvm-svn: 365052
Summary:
This diff improve the capability of DAGCOmbine to generate linear carries propagation in presence of a diamond pattern. It is now able to match a large variety of different patterns rather than some hardcoded one.
Arguably, the codegen in test cases is not better, but this is to be expected. The goal of this transformation is more about canonicalisation than actual optimisation.
Reviewers: hfinkel, RKSimon, craig.topper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D57302
llvm-svn: 365051
If we have more then 2 shuffle ops to combine, try to use combineX86ShuffleChainWithExtract to see if some are from the same super vector.
llvm-svn: 365050
The referenced symbol is expected to point to an R_RISCV_*_HI20
relocation. An absolute symbol has no associated section, therefore
there cannot be a matching R_RISCV_*_HI20.
This fixes the crash reported by PR42038. For reference, ld.bfd errors:
(.init+0x4): dangerous relocation: %pcrel_lo missing matching %pcrel_hi
Differential Revision: https://reviews.llvm.org/D63273
llvm-svn: 365049
This reverts r365015.
David Zarzycki reported this change broke stage2 and stage3 tests. The
root cause is still not very clear, but I guess some SHF_MERGE sections
with the same name have different alignments. They were not merged
before but were merged after r365015.
Something that assumes address uniqueness of such mergeable data caused
the bug.
llvm-svn: 365048
Remove an unnecessary const from an Optional return type introduced
in r364960 that gcc 7.4.0 warns about. It is unnecessary and possibly
incorrect.
llvm-svn: 365047
Summary:
In some setups, using `-fsized-deallocation` would end up not finding
a sized delete operator at link time. For now, avoid using the flag
and declare the sized delete operator in the cpp test only.
This is a tentative fix as I do not have the failing setup.
Reviewers: rnk, morehouse, hctim, eugenis, vitalybuka
Reviewed By: rnk, hctim
Subscribers: mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D64086
llvm-svn: 365045
iff the number of elements doesn't change.
This gets around an issue with combineX86ShuffleChain not being able to hint which domain is preferred for shuffles that can be done with either.
Fixes regression introduced in rL365041
llvm-svn: 365044
When a target intrinsic has been determined to touch memory, we construct a MachineMemOperand during SDAG construction. In this case, we should propagate AAMDNodes metadata to the MachineMemOperand where available.
Differential revision: https://reviews.llvm.org/D64131
llvm-svn: 365043
This patch addresses https://bugs.llvm.org/show_bug.cgi?id=42183 by replacing
the stub markdown doc for llvm-objcopy with a full one describing the current
options available in llvm-objcopy.
Reviewed by: jakehehrlich, MaskRay
Differential Revision: https://reviews.llvm.org/D63820
llvm-svn: 365042
This better accounts for the cost/benefit of removing extract_subvectors from the shuffle and will be more useful in future patches.
The vpermq predicate regression will be fixed shortly.
llvm-svn: 365041
This reapplies 363232 that was reverted due to a buildbot test failure, this build bot has now been fixed.
Differential Revision: https://reviews.llvm.org/D63197
llvm-svn: 365039
libc++abi became mandatory to link the libc++ binaries. LLDB only needs the build artifacts and not the linked output (we don't ship `libc++.dylib` and/or `libc++.a`). Disable the respective link steps to avoid the dependency to libc++abi.
<rdar://problem/51980716>
llvm-svn: 365038
For the following terminator statement:
if (A && B && C && D)
The built CFG is the following:
[B5 (ENTRY)]
Succs (1): B4
[B1]
1: 10
2: j
3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
4: [B1.1] / [B1.3]
5: int x = 10 / j;
Preds (1): B2
Succs (1): B0
[B2]
1: C
2: [B2.1] (ImplicitCastExpr, LValueToRValue, _Bool)
T: if [B4.4] && [B3.2] && [B2.2]
Preds (1): B3
Succs (2): B1 B0
[B3]
1: B
2: [B3.1] (ImplicitCastExpr, LValueToRValue, _Bool)
T: [B4.4] && [B3.2] && ...
Preds (1): B4
Succs (2): B2 B0
[B4]
1: 0
2: int j = 0;
3: A
4: [B4.3] (ImplicitCastExpr, LValueToRValue, _Bool)
T: [B4.4] && ...
Preds (1): B5
Succs (2): B3 B0
[B0 (EXIT)]
Preds (4): B1 B2 B3 B4
However, even though the path of execution in B2 only depends on C's value,
CFGBlock::getCondition() would return the entire condition (A && B && C). For
B3, it would return A && B. I changed this the actual condition.
Differential Revision: https://reviews.llvm.org/D63538
llvm-svn: 365036
gcc may generate .debug_info/.debug_aranges/.debug_line/etc that are
relocated by R_RISCV_ADD*/R_RISCV_SUB* pairs.
Allow R_RISCV_ADD in non-SHF_ALLOC section to fix link errors like:
ld.lld: error: print.c:(.debug_frame+0x60): has non-ABS relocation R_RISCV_ADD64 against symbol '.L0 '
Differential Revision: https://reviews.llvm.org/D63259
llvm-svn: 365035
When specializing a template in a namespace, it has to be in a namespace
block, else gcc will get confused. Hopefully this fixes the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480
llvm-svn: 365030
Transform clang::DominatorTree to be able to also calculate post dominators.
* Tidy up the documentation
* Make it clang::DominatorTree template class (similarly to how
llvm::DominatorTreeBase works), rename it to clang::CFGDominatorTreeImpl
* Clang's dominator tree is now called clang::CFGDomTree
* Clang's brand new post dominator tree is called clang::CFGPostDomTree
* Add a lot of asserts to the dump() function
* Create a new checker to test the functionality
Differential Revision: https://reviews.llvm.org/D62551
llvm-svn: 365028
https://bugs.llvm.org/show_bug.cgi?id=42041
In Clang's CFG, we use nullpointers to represent unreachable nodes, for
example, in the included testfile, block B0 is unreachable from block
B1, resulting in a nullpointer dereference somewhere in
llvm::DominatorTreeBase<clang::CFGBlock, false>::recalculate.
This patch fixes this issue by specializing
llvm::DomTreeBuilder::SemiNCAInfo::ChildrenGetter::Get for
clang::CFG to not contain nullpointer successors.
Differential Revision: https://reviews.llvm.org/D62507
llvm-svn: 365026
Assert that the shift amount is in range and create vXi8 shift masks in a way that doesn't cause MSVC/cppcheck shift result is truncated then extended warnings.
llvm-svn: 365024
Jessica Paquette