| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Replace with '_Vp' for protection against user-defined macros.
llvm-svn: 225527
|
| |
|
|
| |
llvm-svn: 225526
|
| |
|
|
| |
llvm-svn: 225525
|
| |
|
|
| |
llvm-svn: 225524
|
| |
|
|
| |
llvm-svn: 225523
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The P7 benefits from not have really-small loops so that we either have
multiple dispatch groups in the loop and/or the ability to form more-full
dispatch groups during scheduling. Setting the partial unrolling threshold to
44 seems good, empirically, for the P7. Compared to using no late partial
unrolling, this yields the following test-suite speedups:
SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding
-66.3253% +/- 24.1975%
SingleSource/Benchmarks/Misc-C++/oopack_v1p8
-44.0169% +/- 29.4881%
SingleSource/Benchmarks/Misc/pi
-27.8351% +/- 12.2712%
SingleSource/Benchmarks/Stanford/Bubblesort
-30.9898% +/- 22.4647%
I've speculatively added a similar setting for the P8. Also, I've noticed that
the unroller does not quite calculate the unrolling factor correctly for really
tiny loops because it neglects to account for the fact that not every loop body
replicant contains an ending branch and counter increment. I'll fix that later.
llvm-svn: 225522
|
| |
|
|
|
|
| |
options before and after inline asm blocks. NFC.
llvm-svn: 225521
|
| |
|
|
|
|
| |
No functional changes.
llvm-svn: 225520
|
| |
|
|
|
|
|
|
|
|
| |
Before:
void f() __attribute__((override unused))
After:
void f() override __attribute__((unused))
llvm-svn: 225519
|
| |
|
|
|
|
|
|
|
| |
We have a diagnostic describing that constexpr changed in C++14 when
compiling in C++11 mode. While doing this, it examines the previous
declaration and assumes that it is a function. However it is possible,
in the context of error recovery, for this to not be the case.
llvm-svn: 225518
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It can be a constant or a vector argument.
ex :
define i32 @hadd(<4 x i32> %a) #0 {
entry:
%vecext = extractelement <4 x i32> %a, i32 0
%vecext1 = extractelement <4 x i32> %a, i32 1
%add = add i32 %vecext, %vecext1
%vecext2 = extractelement <4 x i32> %a, i32 2
%add3 = add i32 %add, %vecext2
%vecext4 = extractelement <4 x i32> %a, i32 3
%add5 = add i32 %add3, %vecext4
ret i32 %add5
}
llvm-svn: 225517
|
| |
|
|
|
|
| |
integrations.
llvm-svn: 225516
|
| |
|
|
|
|
| |
(I should have re-run the test after running clang-format)
llvm-svn: 225515
|
| |
|
|
|
|
|
|
|
|
|
| |
Parser::ParseNamespace can get a little confused when it found itself
inside a compound statement inside of a non-static data member
initializer.
Try to determine that the statement expression's scope makes sense
before trying to parse it's contents.
llvm-svn: 225514
|
| |
|
|
| |
llvm-svn: 225513
|
| |
|
|
|
|
|
| |
'distinct' was introduced in 225474. We now adjust the test cases
to match for the additional 'distinct' marker.
llvm-svn: 225512
|
| |
|
|
|
|
|
| |
RecordDecls should have things like CXXMethodDecls or FriendDecls as a
decl but not things like FunctionDecls.
llvm-svn: 225511
|
| |
|
|
|
|
| |
Add support for R_ARM_ABS16 relocation mapping. Addresses PR22156.
llvm-svn: 225510
|
| |
|
|
|
|
|
| |
Add an additional test case to ensure that we generate the relocation even if
the thumb target is used.
llvm-svn: 225509
|
| |
|
|
|
|
|
|
| |
We assumed that class-scope specializations would result in a
CXXMethodDecl for that class. However, globally qualified functions
will result in normal FunctionDecls.
llvm-svn: 225508
|
| |
|
|
|
|
| |
Add support for R_ARM_ABS8 relocation. Addresses PR22126.
llvm-svn: 225507
|
| |
|
|
|
|
|
| |
The same code is already in Sema::ActOnFunctionDeclarator, the only
caller of CreateNewFunctionDecl.
llvm-svn: 225506
|
| |
|
|
|
|
|
|
|
| |
Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo.
Don't let the AST contain the malformed lambda.
This fixes PR22122.
llvm-svn: 225505
|
| |
|
|
|
|
|
|
|
|
| |
Allow blessed access to the symbol rewriter from the driver. Although the
symbol rewriter could be invoked through tools like opt and llc, it would not
accessible from the frontend. This allows us to read the rewrite map files in
the frontend rather than the backend and enable symbol rewriting for actually
performing the symbol interpositioning.
llvm-svn: 225504
|
| |
|
|
|
|
|
|
|
| |
The code that eliminated additional coalescable copies in
removeCopyByCommutingDef() used MergeValueNumberInto() which internally
may merge A into B or B into A. In this case A and B had different Def
points, so we have to reset ValNo.Def to the intended one after merging.
llvm-svn: 225503
|
| |
|
|
| |
llvm-svn: 225502
|
| |
|
|
| |
llvm-svn: 225501
|
| |
|
|
| |
llvm-svn: 225500
|
| |
|
|
|
|
| |
Share logic for getting the last instruction emitted.
llvm-svn: 225499
|
| |
|
|
|
|
| |
Prepare to simplify the `DebugLoc` record.
llvm-svn: 225498
|
| |
|
|
|
|
|
| |
This cannot yet be enabled by default, it causes ~50 miscompiles in the test
suite.
llvm-svn: 225497
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The main issue that this patch is trying to address is that the current
implementation of getRerunArgs of InlineTest relies on the attribute
'using_dsym' which could be absent if the test was skipped altogether.
[That is, if both dsym and dwarf tests were skipped.]
While at it, the use of deprecated Python module 'new' is eliminated.
Test Plan: [Linux] dotest.py -p TestExprPathSynthetic
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6888
llvm-svn: 225496
|
| |
|
|
|
|
|
|
|
| |
We were previously emitting counter increments even if we didn't have
an insertion point, which would result in a CallInst with no
parent. This leads to a crash, as in pr22166, if we try to do
GlobalDCE.
llvm-svn: 225495
|
| |
|
|
|
|
|
|
|
|
|
| |
We forgot to mark designated initializer expression that contain type
dependent array designators as type dependent. This would lead to
crashes when we try to determine which array element we were trying to
initialize.
This fixes PR22056.
llvm-svn: 225494
|
| |
|
|
|
|
|
| |
On modern cores with lfiw[az]x, we can fold a sign or zero extension from i32
to i64 into the load necessary for an i64 -> fp conversion.
llvm-svn: 225493
|
| |
|
|
|
|
|
|
|
|
| |
As pointed out by Aditya (and Owen), when we elide an FP extend to form an FMA,
we need to extend the incoming operands so that the resulting node will really
be legal. This is currently enabled only for PowerPC, and it happens to work
there regardless, but this should fix the functionality for everyone else
should anyone else wish to use it.
llvm-svn: 225492
|
| |
|
|
|
|
|
|
|
|
| |
complements the new vector shuffle lowering code path. This flag,
naturally, is *off* because we've not tested or evaluated the results of
this at all. However, the flag will make it much easier to evaluate
whether we can be this aggressive and whether there are missing vector
shuffle lowering optimizations.
llvm-svn: 225491
|
| |
|
|
|
|
|
|
|
|
| |
we're instantiating, if there's a ParmVarDecl within a FunctionDecl context
that is not a parameter of that function. Add some asserts to catch this kind
of issue more generally, and fix another bug exposed by those asserts where we
were missing a local instantiation scope around substitution of
explicitly-specified template arguments.
llvm-svn: 225490
|
| |
|
|
|
|
|
|
|
| |
better than the 'template-parameter-x-y' name that we'd get in AST printing,
and is worse in several ways (it's harder to distinguish it from a
user-supplied name, it's wrong after substituting some number of outer
levels, it wastes time and space constructing an IdentifierInfo, ...).
llvm-svn: 225489
|
| |
|
|
|
|
| |
may have different sizes. Fixes PR22017
llvm-svn: 225488
|
| |
|
|
|
|
|
|
| |
This was used previously for metadata but is no longer needed there. Not
doing this simplifies ValueHandle and will make it easier to fix things
like AssertingVH's DenseMapInfo.
llvm-svn: 225487
|
| |
|
|
|
|
|
|
|
|
|
|
| |
that we can turn them on by default
Change the default of prefer-dynamic-value to eDynamicDontRunTarget (i.e. enable dynamic values, but do not run code to do so)
Of course, disable this for the test suite, since testing no-dynamic-values is actually valuable
Fixes rdar://17363061
llvm-svn: 225486
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As pointed out by Aditya (and Owen), there are two things wrong with this code.
First, it adds patterns which elide FP extends when forming FMAs, and that might
not be profitable on all targets (it belongs behind the pre-existing
aggressive-FMA-formation flag). This is fixed by this change.
Second, the resulting nodes might have operands of different types (the
extensions need to be re-added). That will be fixed in the follow-up commit.
llvm-svn: 225485
|
| |
|
|
|
|
| |
https://code.google.com/p/address-sanitizer/issues/detail?id=368
llvm-svn: 225484
|
| |
|
|
|
|
|
|
| |
Previously, MemDepPrinter handled volatile and unordered accesses without involving MemoryDependencyAnalysis. By making a slight tweak to the documented interface - which is respected by both callers - we can move this responsibility to MDA for the benefit of any future callers. This is basically just cleanup.
In the future, we may decide to extend MDA's non local dependency analysis to return useful results for ordered or volatile loads. I believe (but have not really checked in detail) that local dependency analyis does get useful results for ordered, but not volatile, loads.
llvm-svn: 225483
|
| |
|
|
| |
llvm-svn: 225482
|
| |
|
|
|
|
|
|
|
|
| |
Previously, MemoryDependenceAnalysis::getNonLocalPointerDependency was taking a list of properties about the instruction being queried. Since I'm about to need one more property to be passed down through the infrastructure - I need to know a query instruction is non-volatile in an inner helper - fix the interface once and for all.
I also added some assertions and behaviour clarifications around volatile and ordered field accesses. At the moment, this is mostly to document expected behaviour. The only non-standard instructions which can currently reach this are atomic, but unordered, loads and stores. Neither ordered or volatile accesses can reach here.
The call in GVN is protected by an isSimple check when it first considers the load. The calls in MemDepPrinter are protected by isUnordered checks. Both utilities also check isVolatile for loads and stores.
llvm-svn: 225481
|
| |
|
|
|
|
|
|
| |
This support is still incomplete and consequently hidden behind a switch that
needs to be enabled. One problem is ATM that we incorrectly interpret very large
unsigned values as negative values even if used in an unsigned comparision.
llvm-svn: 225480
|
| |
|
|
|
|
| |
Omission pointed out by Sean Silva!
llvm-svn: 225479
|
| |
|
|
|
|
| |
seem like OOMs)
llvm-svn: 225478
|