The example code incorrectly invokes ScheduleDAGMI wherein from context
it is clear it intends to invoke ScheduleDAGMILive actually.
Reviewed by: Andrew Trick
Differential Revision: https://reviews.llvm.org/D34675
llvm-svn: 306424
Not sure why this restriction existed, but it seems like we should support any size Constant here.
The particular pattern in the tests is not the only use of this matcher in the tree. There's one in CodeGenPrepare and one in InstSimplify as well.
Differential Revision: https://reviews.llvm.org/D34666
llvm-svn: 306417
Summary: This allows check-all to be used when only a subset of the sanitizers are built.
Reviewers: beanz, compnerd
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34644
llvm-svn: 306415
•static latency
•number of uOps from which the instructions consists
•all ports used by the instruction
Reviewers:
RKSimon
zvi
aymanmus
m_zuckerman
Differential Revision: https://reviews.llvm.org/D33897
llvm-svn: 306414
Summary:
1. Instruction V_CVT_U32_F32 allow omod operand (see SIInstrInfo.td:1435). In fact this operand shouldn't be allowed here. This fix checks if SDWA pseudo instruction has OMod operand and then copy it.
2. There were several problems with support of VOPC instructions in SDWA peephole pass.
Reviewers: tstellar, arsenm, vpykhtin, airlied, kzhuravl
Subscribers: wdng, nhaehnle, yaxunl, dstuttard, tpr, sarnex, t-tye
Differential Revision: https://reviews.llvm.org/D34626
llvm-svn: 306413
This patch modifies the conditional compares pass so that it keeps successor
probabilities up-to-date after the conversion. Previously, successor
probabilities were being normalized to a uniform distribution, even though they
may have been heavily biased prior to the conversion (e.g., if one of the edges
was the back edge of a loop). This loss of information affected passes later in
the pipeline.
Differential Revision: https://reviews.llvm.org/D34109
llvm-svn: 306412
Instead of getBackEdgeTakenCount, use getExitCount on the latch exiting block
(which is proven to be the only exiting block in the loop to be unrolled).
llvm-svn: 306410
Summary:
This patch adds support for <>-style proto message fields inside proto options.
Previously these were wrongly treated as binary operators and as such were
working only by chance for a limited number of cases.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34621
llvm-svn: 306406
Add the instruction aliases for ds(r|l)l for the two operand alias
of ds(r|l)lv and the aliases ds(r|l)l with the three register operands.
llvm-svn: 306405
When SelectionDAG merges consecutive stores and loads in MergeConsecutiveStores, it does not set dereferenceable flag for a created load instruction. This results in an assertion failure if SelectionDAG commonizes this load instruction with other load instructions, as well as it may miss optimization opportunities.
This patch sat dereferenceable flag for the newly created load instruction if all the load instructions to be merged are dereferenceable.
Differential Revision: https://reviews.llvm.org/D34679
llvm-svn: 306404
[X86][AVX512] Improve lowering of AVX512 compare intrinsics (remove redundant shift left+right instructions).
AVX512 compare instructions return v*i1 types.
In cases where the number of elements in the returned value are less than 8, clang adds zeroes to get a mask of v8i1 type.
Later on it's replaced with CONCAT_VECTORS, which then is lowered to many DAG nodes including insert/extract element and shift right/left nodes.
The fact that AVX512 compare instructions put the result in a k register and zeroes all its upper bits allows us to remove the extra nodes simply by copying the result to the required register class.
When lowering, identify these cases and transform them into an INSERT_SUBVECTOR node (marked legal), then catch this pattern in instructions selection phase and transform it into one avx512 cmp instruction.
Differential Revision: https://reviews.llvm.org/D33188
llvm-svn: 306402
Before we would 'guess' the correct location for the MergeBlock
that got introduced when executing a Scop conditionally. This
implicitly depends on the situation that at this point during
CodeGen there will be nothing between polly.start and polly.exiting.
With this commit we explicitly state that we want the block that
directly follows polly.exiting.
llvm-svn: 306398
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
This is a new checker package. It contains checkers that highlight
well-documented implementation-defined behavior. Such checkers are only useful
to developers that intend to write portable code. Code that is only compiled for
a single platform should be allowed to rely on this platform's specific
documented behavior.
rdar://problem/30545046
Differential Revision: https://reviews.llvm.org/D34102
llvm-svn: 306396
This test fails, if polly is not linked into LLVM's tools. Our
lit site-config already deals with this by not adding the -load
option, if polly is linked into LLVM's tools.
llvm-svn: 306395
Summary:
It had a dependency on StringConvert and file reading code, which is not
in Utility. I've replaced that code by equivalent llvm operations.
I've added a unit test to demonstrate that parsing a file still works.
Reviewers: zturner, jingham
Subscribers: kubamracek, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34625
llvm-svn: 306394
dependent initializer
This commit fixes incorrect source positions of dependent c'tor initializers
like in the following code:
template<typename MyBase>
struct Derived: MyBase::InnerIterator
{
Derived() : MyBase::InnerIterator() {} /// This line is problematic: all positions point to InnerIterator and nothing points to MyBase
};
Patch by Serge Preis!
Differential Revision: https://reviews.llvm.org/D32439
llvm-svn: 306392
Summary:
These interfaces have no dependencies, so it makes sense for them to be
in the lowest level modules, to make sure that other parts of the
codebase can use them without introducing loops.
The only exception here is the Connection::CreateDefaultConnection
method, which I've moved to Host, as it instantiates concrete
implementations, and that's where the implementations live.
Reviewers: jingham, zturner
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34400
llvm-svn: 306391
Summary:
After this patch, we finally have test cases that require multiple
instruction emission.
Depends on D33590
Reviewers: ab, qcolombet, t.p.northover, rovka, kristof.beyls
Subscribers: javed.absar, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D33596
llvm-svn: 306388
Borrow from the logic for 'jal' in MipsAsmParser::processInstruction
and add the extra condition of bypassing CALL16 if the destination symbol
is an ELF symbol with STB_LOCAL binding.
Patch by: John Baldwin
Reviewers: sdardis
Differential Revision: https://reviews.llvm.org/D33999
llvm-svn: 306387
D31709 [NFC] Refactor DiagnosticRenderer to use FullSourceLoc was committed
in r305684 and reverted in 305688 as clang-tidy and clang-query failed to
build. This change updates the extra tools to use the new interface.
Reviewers: christof, rnk, rsmith, rovka, alexfh
Reviewed By: alexfh
Differential Revision: https://reviews.llvm.org/D34513
llvm-svn: 306385
This reverts commit r305688 meaning it reintroduces r305684. To repeat:
[NFC] Refactor DiagnosticRenderer to use FullSourceLoc
Move the DiagnosticRenderer and its dependents to using FullSourceLocs
instead of a SourceLocation and SourceManager pointer. The changeset is
rather large but entirely mechanical.
This is step one to allow DiagnosticRenderer to take either
llvm::SMLocs or clang::SourceLocations.
This breaks clang-tidy and clng-query which will be fixed in a commit
soon after.
Patch by Sanne Wouda
Differential Revision: https://reviews.llvm.org/D31709
llvm-svn: 306384
* Mark as legal for (s32, i1, s32, s32)
* Map everything into GPRs
* Select to two instructions: a CMP of the condition against 0, to set
the flags, and a MOVCCr to select between the two inputs based on the
flags that we've just set
llvm-svn: 306382
Undoing revert 306338 after fixed bug: add metadata to the load instead of the
reverse shuffle added to it, retaining the original ValueMap implementation.
llvm-svn: 306381
This is based heavily on the work done ni D34285. I mostly wanted to do
test cleanup for the author to save them some time, but I had a really
hard time understanding why it was so hard to write better test cases
for these issues.
The problem is that because SROA does a second rewrite of the loads and
because we *don't* propagate !nonnull for non-pointer loads, we first
introduced invalid !nonnull metadata and then stripped it back off just
in time to avoid most ways of this PR manifesting. Moving to the more
careful utility only fixes this by changing the predicate to look at the
new load's type rather than the target type. However, that *does* fix
the bug, and the utility is much nicer including adding range metadata
to model the nonnull property after a conversion to an integer.
However, we have bigger problems because we don't actually propagate
*range* metadata, and the utility to do this extracted from instcombine
isn't really in good shape to do this currently. It *only* handles the
case of copying range metadata from an integer load to a pointer load.
It doesn't even handle the trivial cases of propagating from one integer
load to another when they are the same width! This utility will need to
be beefed up prior to using in this location to get the metadata to
fully survive.
And even then, we need to go and teach things to turn the range metadata
into an assume the way we do with nonnull so that when we *promote* an
integer we don't lose the information.
All of this will require a new test case that looks kind-of like
`preserve-nonnull.ll` does here but focuses on range metadata. It will
also likely require more testing because it needs to correctly handle
changes to the integer width, especially as SROA actively tries to
change the integer width!
Last but not least, I'm a little worried about hooking the range
metadata up here because the instcombine logic for converting from
a range metadata *to* a nonnull metadata node seems broken in the face
of non-zero address spaces where null is not mapped to the integer `0`.
So that probably needs to get fixed with test cases both in SROA and in
instcombine to cover it.
But this *does* extract the core PR fix from D34285 of preventing the
!nonnull metadata from being propagated in a broken state just long
enough to feed into promotion and crash value tracking.
On D34285 there is some discussion of zero-extend handling because it
isn't necessary. First, the new load size covers all of the non-undef
(ie, possibly initialized) bits. This may even extend past the original
alloca if loading those bits could produce valid data. The only way its
valid for us to zero-extend an integer load in SROA is if the original
code had a zero extend or those bits were undef. And we get to assume
things like undef *never* satifies nonnull, so non undef bits can
participate here. No need to special case the zero-extend handling, it
just falls out correctly.
The original credit goes to Ariel Ben-Yehuda! I'm mostly landing this to
save a few rounds of trivial edits fixing style issues and test case
formulation.
Differental Revision: D34285
llvm-svn: 306379
Summary:
If the class being created in unique_ptr is in anonymous nampespace, the
anonymous namespace will be included in the apply-fixes. This patch fix
this.
```
namespace {
class Foo {};
}
std::unique_ptr<Foo> f;
f.reset(new Foo());
// Before the change: f = std::make_unique<(annonymous namespace)::Foo>();
// After the change: f = std::make_unique<Foo>();
```
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D34286
llvm-svn: 306378
Xinliang David Li