| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
succesor -> successor
llvm-svn: 306393
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
All we need to do is mark it as legal, otherwise it's just like s32.
llvm-svn: 306390
|
| |
|
|
| |
llvm-svn: 306389
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The test suite was missing a test about associative maps:
https://developers.google.com/protocol-buffers/docs/proto3#maps
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34623
llvm-svn: 306386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Implements TargetInfo class for Nios2 target.
- Enables handling of -march and -mcpu options for Nios2 target.
- Definition of Nios2 builtin functions.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D33356
Author: belickim <mateusz.belicki@intel.com>
llvm-svn: 306383
|
| |
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
| |
to surpress warnings. ppc970 should be 970 (or g5)
llvm-svn: 306380
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CK_ConstructorConversion
With
struct S1 {};
struct S2 { operator S1(); };
S1 f(S2 s) { return static_cast<S1>(s); }
the static_cast expr is
CXXStaticCastExpr 0x... 'struct S1' static_cast<struct S1> <ConstructorConversion>
`-CXXConstructExpr 0x... 'struct S1' 'void (struct S1 &&) noexcept' elidable
`-MaterializeTemporaryExpr 0x... 'struct S1' xvalue
`-ImplicitCastExpr 0x... 'struct S1' <UserDefinedConversion>
`-CXXMemberCallExpr 0x... 'struct S1'
`-MemberExpr 0x... '<bound member function type>' .operator S1 0x...
`-DeclRefExpr 0x... 'struct S2' lvalue ParmVar 0x... 's' 'struct S2'
getSubExprAsWritten used to return the MaterializeTemporaryExpr (of type S1)
under the CXXConstructExpr, instead of unwinding further to the DeclRefExpr (of
type S2) at the bottom.
Differential Revision: https://reviews.llvm.org/D22128
llvm-svn: 306377
|
| |
|
|
| |
llvm-svn: 306376
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With scalar stores, M0 is clobbered and therefore marked as implicitly
defined. However, it is also dead.
This fixes an assertion when the Greedy Register Allocator decides to
optimize a spill/restore pair away again (via tryHintsRecoloring).
Reviewers: arsenm
Subscribers: qcolombet, kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D33319
llvm-svn: 306375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... once each for the syntactic and semantic form. Without this fix, behavior
of the newly added tests would have been
InitListExprIsPreOrderVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderVisitedTwice:
syntactic: 0
semantic: 1
InitListExprIsPreOrderNoQueueVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderNoQueueVisitedTwice:
syntactic: 0
semantic: 2
llvm-svn: 306374
|
| |
|
|
|
|
|
|
|
|
|
|
| |
...instead of -std=c99, as the latter lead to
error: invalid argument '-std=c99' not allowed with 'C++'
complaints in test logs
Differential Revision: https://reviews.llvm.org/D34417
llvm-svn: 306373
|
| |
|
|
| |
llvm-svn: 306372
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
patterns.
All patterns reside in a std::vector container, where new variants are added to it using the standard library's emplace_back function.
When calling this with a new element while there is no enough allocated space, a bigger space is allocated and all the old info in the small vector is copied to the newly allocated vector, then the old vector is freed.
The problem is that before doing this "copying", we take a reference of one of the elements in the old vector, and after the "copying" we add it to the new vector.
As the old vector is freed after the copying, the reference now does not point to a valid element.
Added new function to the API of CodeGenDAGPatterns class to return the same information as a copy in order to avoid this issue.
This was revealed in rL305465 that added many patterns and forced the reallocation of the vector which caused crashes in windows bots.
Differential Revision: https://reviews.llvm.org/D34341
llvm-svn: 306371
|
| |
|
|
|
|
| |
G_FADD, G_FSUB, G_FMUL, G_FDIV. NFC.
llvm-svn: 306370
|
| |
|
|
| |
llvm-svn: 306369
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
EraseInst didn't report that it made IR changes through MadeChange.
It is essential that changes to the IR are reported correctly,
since for example ReassociatePass::run() will indicate that all
analyses are preserved otherwise.
And the CGPassManager determines if the CallGraph is up-to-date
based on status from InstructionCombiningPass::runOnFunction().
Reviewers: craig.topper, rnk, davide
Reviewed By: rnk, davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34616
llvm-svn: 306368
|
| |
|
|
|
|
|
|
|
| |
PowerPC backend does not pass the current optimization level to SelectionDAGISel and so SelectionDAGISel works with the default optimization level regardless of the current optimization level.
This patch makes the PowerPC backend set the optimization level correctly.
Differential Revision: https://reviews.llvm.org/D34615
llvm-svn: 306367
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixed IMAGE_REL_ARM64_PAGEBASE_REL2 ==> IMAGE_REL_ARM64_PAGEBASE_REL21
Refer: http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
Reviewers: zturner, rnk, ruiu
Reviewed By: ruiu
Subscribers: aemerson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D34659
llvm-svn: 306366
|
| |
|
|
|
|
| |
select+cmp+cttz/ctlz when the bitwidth is larger than 64 bits.
llvm-svn: 306365
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the documentation, when encoding a bit-field, GNU runtime
needs its starting position in addition to its type and size.
https://gcc.gnu.org/onlinedocs/gcc/Type-encoding.html
Prior to r297702, the starting position information was not being
encoded, which is incorrect, and after r297702, an assertion started to
fail because an ObjCIvarDecl was being passed to a function expecting a
FieldDecl.
This commit moves LookupFieldBitOffset to ASTContext and uses the
function to encode the starting position of bit-fields.
llvm-svn: 306364
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rafael, dylanmckay, jroelofs, meadori
Reviewed By: rafael, meadori
Subscribers: meadori, llvm-commits
Differential Revision: https://reviews.llvm.org/D34551
llvm-svn: 306359
|
| |
|
|
|
|
| |
the nonnull attribute distinct from rewriting it into an assume.
llvm-svn: 306358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've found it very difficult to get test/parallel/omp_nested.c to pass
consistently across my build environments. The problem is that it creates N^2
threads (it is testing nested parallel regions), and that often exceeds the
thread limits on systems with many cores. We do raise the process limits in
lit, and that often helps, but if running lit with a smaller number of threads
or on a system where we're otherwise resource constrained, this particular test
tends to fail (because the runtime cannot create a sufficient number of
threads).
This seems to work: if the maximum number of threads is more than some small
number, then cap the number of threads used for the parallel region. The choice
of 4 here is somewhat arbitrary.
Differential Revision: https://reviews.llvm.org/D32033
llvm-svn: 306357
|
| |
|
|
|
|
|
| |
Also, while here, remove an unneeded `using namespace llvm`.
Thanks to George for the suggestion.
llvm-svn: 306355
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34660
llvm-svn: 306354
|
| |
|
|
|
|
| |
nonnull as part of fixing PR32902.
llvm-svn: 306353
|
| |
|
|
|
|
|
|
|
| |
Remove invalid shortcut in fixupKills(): A register needs to be marked
live even when we are not adding a kill flag. This is because a
partially live register must not get a kill flags, but it still needs to
be fully marked live when walking backwards.
llvm-svn: 306352
|
| |
|
|
|
|
|
|
|
| |
Using Optional<> here doesn't seem to be terribly valuable, but
this is not the main point of this change. The change enables
us to merge the (now) two identical copies of parentFunctionOfValue()
that Steensgaard's and Andersens' provide.
llvm-svn: 306351
|
| |
|
|
| |
llvm-svn: 306350
|
| |
|
|
|
|
| |
happen when testing -Wpadded.
llvm-svn: 306349
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34638
llvm-svn: 306348
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When generating the decorated name for a static variable inside a
BlockDecl, construct a scope for the block invocation function that
homes the parameter. This allows for arbitrary nesting of the blocks
even if the variables are shadowed. Furthermore, using this for the name
allows for undname to properly undecorated the name for us. It shows up
as the synthetic __block_invocation function that the compiler emitted
in the local scope.
llvm-svn: 306347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also add testcases for a bunch of expression forms that cause our evaluator to
crash. See PR33140 and PR32864 for crashes that this was causing.
This reverts r305287, which reverted r305239, which reverted r301742. The
previous revert claimed that buildbots were broken, but did not add any
testcases and the buildbots have lost all memory of what was wrong here.
Changes to test/OpenMP are not reverted; another change has triggered those
tests to change their output in the same way that r301742 did.
llvm-svn: 306346
|
| |
|
|
|
|
|
|
|
|
|
|
| |
truncation and extension match.
This fixes PR33368.
Reviewer: rksimon
Differential Revision: https://reviews.llvm.org/D34069
llvm-svn: 306345
|
| |
|
|
| |
llvm-svn: 306344
|