| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 321323
|
|
|
|
| |
llvm-svn: 321322
|
|
|
|
| |
llvm-svn: 321321
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D41414
llvm-svn: 321320
|
|
|
|
|
|
|
| |
Canonicalizing the Decl before processing it as part of the hash should reduce
issues with non-canonical types showing up as mismatches.
llvm-svn: 321319
|
|
|
|
|
|
|
|
| |
This is a slightly odd construct (it's more common to see "A (::B)()") but can
happen in friend declarations, and the parens are not redundant as they prevent
the :: binding to the left.
llvm-svn: 321318
|
|
|
|
|
|
|
| |
This small function was showing up in the profile. Defining it inline
gives about 0.3% speedup.
llvm-svn: 321317
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable assertions in both stages.
Release+Asserts is fast enough.
No need to let insanity through.
Patch By: mcgrathr
Reviewers: phosek
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D41471
llvm-svn: 321316
|
|
|
|
|
|
|
|
| |
extract_vector_elt from vXi1 with a non-const index.
We have a better range of instructions we can use if we can fill with the value i1 value rather than zeroing.
llvm-svn: 321315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently the -fsanitize flag hadn't been added for Scudo upstream yet.
Patch By: flowerhack
Reviewers: cryptoad, alekseyshl, mcgrathr, phosek
Reviewed By: mcgrathr, phosek
Differential Revision: https://reviews.llvm.org/D41413
llvm-svn: 321314
|
|
|
|
| |
llvm-svn: 321313
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope, as its visibility is
global.
In the case of scoped enumerations, they must include information
about their enclosing scope.
Patch by Carlos Alberto Enciso!
Differential Revision: https://reviews.llvm.org/D39239
llvm-svn: 321312
|
|
|
|
|
|
|
|
|
| |
It is a pretty expensive function. Some of the speedups:
clang: 1.92%
chrome: 1.15%
linux-kernel: 1.40%
llvm-svn: 321311
|
|
|
|
|
|
|
|
| |
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.
llvm-svn: 321310
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases.
Shift existing Mod/Ref/ModRef values to include an additional most
significant bit. Update wrappers that modify ModRefInfo values to
reflect the change.
Notes:
* ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it.
* Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA).
* GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost.
* There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location.
Reviewers: dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38862
llvm-svn: 321309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently the test only checks behaviour for weak function symbols.
Should be good to merge straight away?
Reviewers: sbc100
Reviewed By: sbc100
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D41449
llvm-svn: 321308
|
|
|
|
|
|
|
|
|
|
|
|
| |
redeclared."
This reverts commit r321296. It caused performance regressions
FAIL: imp.execution_time
FAIL: 2007-01-04-KNR-Args.execution_time
FAIL: sse_expandfft.execution_time
FAIL: sse_stepfft.execution_time
llvm-svn: 321306
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The public sanitizer headers are intended to be usable from either
C++ or C, but they declare no-argument functions with the syntax that
is not a proper prototype declaration in C. This goes unnoticed until
someone uses -Wsystem-headers.
Patch By: mcgrathr
Reviewers: phosek, vitalybuka
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D41475
llvm-svn: 321305
|
|
|
|
|
|
|
| |
The parentheses here are not redundant as they affect the binding of the
'::' token.
llvm-svn: 321304
|
|
|
|
|
|
|
|
| |
512-bit if we have VLX.
This should only affect what we do for v8i16. Previously we went to v8i64, but if we have VLX we only need v8i32. This prevents an unnecessary zmm usage.
llvm-svn: 321303
|
|
|
|
| |
llvm-svn: 321302
|
|
|
|
|
|
| |
Differential Revision: https:://reviews.llvm.org/D41360
llvm-svn: 321301
|
|
|
|
|
|
|
|
| |
This can be used to customize the libc++ build.
Differential Revision: https://reviews.llvm.org/D41103
llvm-svn: 321299
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r321239. It broke the Chromium DLL build:
[8834/50217] LINK(DLL) icui18n.dll icui18n.dll.lib icui18n.dll.pdb
FAILED: icui18n.dll icui18n.dll.lib icui18n.dll.pdb
zrule.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) public: void __cdecl icu_60::UnicodeString::`vbase destructor'(void)"
(__imp_??_DUnicodeString@icu_60@@QEAAXXZ)
llvm-svn: 321298
|
|
|
|
|
|
| |
Otherwise it will serve as a deduction guide for the wrong class template.
llvm-svn: 321297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a function taking transparent union is declared as taking one of
union members earlier in the translation unit, clang would hit an
"Invalid cast" assertion during EmitFunctionProlog. This case
corresponds to function f1 in test/CodeGen/transparent-union-redecl.c.
We decided to cast i32 to union because after merging function
declarations function parameter type becomes int,
CGFunctionInfo::ArgInfo type matches with ABIArgInfo type, so we decide
it is a trivial case. But these types should also be castable to
parameter declaration type which is not the case here.
The fix is in checking for the trivial case if ABIArgInfo type matches with
parameter declaration type. It exposed inconsistency that we check
hasScalarEvaluationKind for different types in EmitParmDecl and
EmitFunctionProlog, and comment says they should match.
Additional tests in Sema/transparent-union.c capture current behavior and make
sure there are no regressions.
rdar://problem/34949329
Reviewers: rjmccall, rafael
Reviewed By: rjmccall
Subscribers: aemerson, cfe-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D41311
llvm-svn: 321296
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reorganizes the DWARF consumer to derive the string offsets table
contribution's format from the contribution header instead of
(incorrectly) from the unit's format.
Reviewers: JDevliegehere, aprantl
Differential Revision: https://reviews.llvm.org/D41146
llvm-svn: 321295
|
|
|
|
|
|
|
|
| |
Putting back the code that was reverted few weeks ago.
Differential Revision: https://reviews.llvm.org/D34161
llvm-svn: 321294
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r321260. It appears to have broken the sanitizer
bot sanitizer-ppc64be-linux.
http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/5029
Reverting to see if the buildbot turns green.
llvm-svn: 321292
|
|
|
|
|
|
|
|
| |
We should have equally good shuffle options for v8i32 with VLX. This was spotted during my attempts to remove 512-bit vectors from SKX.
We still use 512-bits for v16i1, v32i1, and v64i1. I'm less sure we can handle those well with narrower vectors. i32 and i64 element sizes get the best shuffle support.
llvm-svn: 321291
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using ARC, strong, weak, and autoreleasing stack variables are implicitly
initialized with nil. This includes variable-length arrays of Objective-C object
pointers. However, in the analyzer we don't zero-initialize them. We used to,
but it accidentally regressed after r289618.
Under ARC, the array variable's initializer within DeclStmt is an
ImplicitValueInitExpr. Environment doesn't maintain any bindings for this
expression kind - instead it always knows that it's a known constant
(0 in our case), so it just returns the known value by calling
SValBuilder::makeZeroVal() (see EnvironmentManager::getSVal().
Commit r289618 had introduced reasonable behavior of SValBuilder::makeZeroVal()
for the arrays, which produces a zero-length compoundVal{}. When such value
is bound to arrays, in RegionStoreManager::bindArray() "remaining" items in the
array are default-initialized with zero, as in
RegionStoreManager::setImplicitDefaultValue(). The similar mechanism works when
an array is initialized by an initializer list that is too short, eg.
int a[3] = { 1, 2 };
would result in a[2] initialized with 0. However, in case of variable-length
arrays it didn't know if any more items need to be added,
because, well, the length is variable.
Add the default binding anyway, regardless of how many actually need
to be added. We don't really care how many, because the default binding covers
the whole array anyway.
Differential Revision: https://reviews.llvm.org/D41478
rdar://problem/35477763
llvm-svn: 321290
|
|
|
|
|
|
|
|
| |
Patch to allow detectAVGPattern handle vectors larger than the legal size (128 SSE2, 256 AVX2, 512 AVX512BW), splitting the vectors accordingly.
Differential Revision: https://reviews.llvm.org/D41440
llvm-svn: 321288
|
|
|
|
|
|
| |
Found by asan.
llvm-svn: 321286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* While running ASTImporterTests, we often forget about Windows MSVC
buildbots which enable '-fdelayed-template-parsing' by default.
This leads to AST import errors because templates are not parsed
and corresponding parts of AST are not built so importer cannot import them.
It takes both reviewing time to find such issues and post-commit time
to fix unexpected buildbot failures. To solve this issue, we enable testing
with '-fdelayed-template-parsing' option enabled by default in addition
to testing with default compiler options. This allows us to catch
the problem during development.
Differential Revision: https://reviews.llvm.org/D41444
llvm-svn: 321285
|
|
|
|
| |
llvm-svn: 321284
|
|
|
|
|
|
|
|
| |
Previous YAML quoting patches broke UTF-8 printing in YAML: see https://reviews.llvm.org/D41290#961801.
Differential Revision: https://reviews.llvm.org/D41490
llvm-svn: 321283
|
|
|
|
|
|
| |
Dump the failing TreePattern.
llvm-svn: 321282
|
|
|
|
|
|
| |
More general cases are already handled by constant canonicalization and then the ReassociateOps call at line 5327
llvm-svn: 321280
|
|
|
|
|
|
|
|
| |
combine to work on non-splat vectors
The knownbits_mask_or_shuffle_uitofp change is interesting - shuffle combines manage to kick in, removing the AND constant mask load. For targets with fast-variable-shuffle this should reduce further to VPOR+VPSHUFB+VCVTDQ2PS.
llvm-svn: 321279
|
|
|
|
| |
llvm-svn: 321278
|
|
|
|
|
|
| |
This test was also using "a" in an expression.
llvm-svn: 321277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build failure was caused by an assertion in pre-legalization DAGCombine:
Combining: t6: ppcf128 = uint_to_fp t5
... into: t20: f32 = PPCISD::FCFIDUS t19
which is clearly wrong since ppcf128 are definitely different type with f32 and
we cannot change the node value type when do DAGCombine. The fix is don't
handle ppc_fp128 or i1 conversions in PPCTargetLowering::combineFPToIntToFP and
leave it to downstream to legalize it and expand it to small legal types.
Differential Revision: https://reviews.llvm.org/D41411
llvm-svn: 321276
|
|
|
|
|
|
| |
work on non-splat vectors
llvm-svn: 321275
|
|
|
|
|
|
|
|
| |
During the review of D40362 I spotted that this test wasn't actually
testing the eva instructions due to '-mattr==eva', rather than '-mattr=+eva',
which resulted in test having no effect.
llvm-svn: 321273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Symbols are not self-contained - it's only safe to hand them out if you
guarantee the lifetime of the underlying data.
Before this lands, I'm going to measure the before/after memory usage of the
LLVM index loaded into memory in a single slab.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, cfe-commits
Differential Revision: https://reviews.llvm.org/D41483
llvm-svn: 321272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two tests were failing because the debugger was picking up multiply
defined internal symbols from the system libraries. This is a bug, as
there should be no ambiguity because the tests are defining variables
with should shadow these symbols, but lldb is not smart enough to figure
that out.
I work around the issue by renaming the variables in these tests, and in
exchange I create a self-contained test which reproduces the issue
without depending on the system libraries.
This increases the predictability of our test suite.
llvm-svn: 321271
|
|
|
|
| |
llvm-svn: 321270
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function is defined in OpenMP-TR6 section 4.1.5.1.6
The functions was not implemented yet.
Since ompt-functions can only be called after the runtime was initialized and
has loaded a tool, it can assume the runtime to be initialized. In contrast
to omp_get_num_procs which needs to check whether the runtime is initialized.
Differential Revision: https://reviews.llvm.org/D40949
llvm-svn: 321269
|
|
|
|
| |
llvm-svn: 321268
|
|
|
|
| |
llvm-svn: 321267
|