We had no such test.

llvm-svn: 347552

Summary: The fix for `auto` new expression is illegal.

Reviewers: aaron.ballman

Subscribers: xazax.hun, cfe-commits

Differential Revision: https://reviews.llvm.org/D54832

llvm-svn: 347551

"--split-stack-adjust-size: size must be >= 0" message
was never tested.

llvm-svn: 347550

When we are in a error state, script parser will not parse the -defsym
expression and hence will not tokenize it. Then ScriptLexer::Pos will be 0
and LLD will assert and crash here:

MemoryBufferRef ScriptLexer::getCurrentMB() {
  assert(!MBs.empty() && Pos > 0); // Bang !

Solution - stop parsing the defsym in a error state. That is consistent
with the regular case (when we parse the linker script).

llvm-svn: 347549

Summary:
This improves cross-namespace completions and has ignorable
impact on other completion types.

Metrics
```
==================================================================================================
                                        OVERALL (excl. CROSS_NAMESPACE)
==================================================================================================
  Total measurements: 109367 (-6)
  All measurements:
	MRR: 68.11 (+0.04)	Top-1: 58.59% (+0.03%)	Top-5: 80.00% (+0.01%)	Top-100: 95.92% (-0.02%)
  Full identifiers:
	MRR: 98.35 (+0.09)	Top-1: 97.87% (+0.17%)	Top-5: 98.96% (+0.01%)	Top-100: 99.03% (+0.00%)
  Filter length 0-5:
	MRR:      23.20 (+0.05)		58.72 (+0.01)		70.16 (-0.03)		73.44 (+0.03)		76.24 (+0.00)		80.79 (+0.14)
	Top-1:    11.90% (+0.03%)		45.07% (+0.03%)		58.49% (-0.05%)		62.44% (-0.02%)		66.31% (-0.05%)		72.10% (+0.07%)
	Top-5:    35.51% (+0.08%)		76.94% (-0.01%)		85.10% (-0.13%)		87.40% (-0.02%)		88.65% (+0.01%)		91.84% (+0.17%)
	Top-100:  83.25% (-0.02%)		96.61% (-0.15%)		98.15% (-0.02%)		98.43% (-0.01%)		98.53% (+0.01%)		98.66% (+0.02%)

==================================================================================================
                                        CROSS_NAMESPACE
==================================================================================================
  Total measurements: 17702 (+27)
  All measurements:
	MRR: 28.12 (+3.26)	Top-1: 21.07% (+2.70%)	Top-5: 35.11% (+4.48%)	Top-100: 74.31% (+1.02%)
  Full identifiers:
	MRR: 79.20 (+3.72)	Top-1: 71.78% (+4.86%)	Top-5: 88.39% (+2.84%)	Top-100: 98.99% (+0.00%)
  Filter length 0-5:
	MRR:      0.92 (-0.10)		5.51 (+0.57)		18.30 (+2.34)		21.62 (+3.76)		32.00 (+6.00)		41.55 (+7.61)
	Top-1:    0.56% (-0.08%)		2.44% (+0.15%)		9.82% (+1.47%)		12.59% (+2.16%)		21.17% (+4.47%)		30.05% (+6.72%)
	Top-5:    1.20% (-0.15%)		7.14% (+1.04%)		25.17% (+3.91%)		29.74% (+5.90%)		43.29% (+9.59%)		54.75% (+9.79%)
	Top-100:  5.49% (-0.01%)		56.22% (+2.59%)		86.69% (+1.08%)		89.03% (+2.04%)		93.74% (+0.78%)		96.99% (+0.59%)
```

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D54851

llvm-svn: 347548

llvm-svn: 347547

llvm-svn: 347546

We can now select CLZ via the TableGen'erated code, so support G_CTLZ
and G_CTLZ_ZERO_UNDEF throughout the pipeline for types <= s32.

Legalizer:
If the CLZ instruction is available, use it for both G_CTLZ and
G_CTLZ_ZERO_UNDEF. Otherwise, use a libcall for G_CTLZ_ZERO_UNDEF and
lower G_CTLZ in terms of it.

In order to achieve this we need to add support to the LegalizerHelper
for the legalization of G_CTLZ_ZERO_UNDEF for s32 as a libcall (__clzsi2).

We also need to allow lowering of G_CTLZ in terms of G_CTLZ_ZERO_UNDEF
if that is supported as a libcall, as opposed to just if it is Legal or
Custom. Due to a minor refactoring of the helper function in charge of
this, we will also allow the same behaviour for G_CTTZ and G_CTPOP.
This is not going to be a problem in practice since we don't yet have
support for treating G_CTTZ and G_CTPOP as libcalls (not even in
DAGISel).

Reg bank select:
Map G_CTLZ to GPR. G_CTLZ_ZERO_UNDEF should not make it to this point.

Instruction select:
Nothing to do.

llvm-svn: 347545

llvm-svn: 347544

We explicitly call finalizeContents() only once for
DynamicSection. The code testing we do not do it twice is
just excessive.

It could be an assert, but we don't do
that for other sections, so does not seem we
should do it here too.

llvm-svn: 347543

Both zext and sext are currently allowed during the search for narrow
sequences and sexts operands are later added to the mac candidates.
But operands of muls are also added, without checking whether they're
sext or zext, which means we can generate a signed smlad when we
shouldn't.

Differential Revision: https://reviews.llvm.org/D54790

llvm-svn: 347542

This reverts commit r346970.
It was causing PR39774, a crash in slp-vectorizer on a rather simple loop
with just a bunch of 'and's in the body.

llvm-svn: 347541

We never should call writeTo() for BSS section.

llvm-svn: 347540

- fix compile error on older gcc in Protocol.cpp,
- remove redundant 'llvm::' qualifiers from Protocol.cpp,
- remove unused variables in AST.cpp

llvm-svn: 347539

Summary:
Instead of receiving compilation commands, auto-index is triggered by just
filenames to reindex, and gets commands from the global comp DB internally.
This has advantages:
 - more of the work can be done asynchronously (fetching compilation commands
   upfront can be slow for large CDBs)
 - we get access to the CDB which can be used to retrieve interpolated commands
   for headers (useful in some cases where the original TU goes away)
 - fits nicely with the filename-only change observation from r347297

The interface to GlobalCompilationDatabase gets extended: when retrieving a
compile command, the GCDB can optionally report the project the file belongs to.
This naturally fits together with getCompileCommand: it's hard to implement one
without the other. But because most callers don't care, I've ended up with an
awkward optional-out-param-in-virtual method pattern - maybe there's a better
one.

This is the main missing integration point between ClangdServer and
BackgroundIndex, after this we should be able to add an auto-index flag.

Reviewers: ioeric, kadircet

Subscribers: MaskRay, jkorous, arphaman, cfe-commits, ilya-biryukov

Differential Revision: https://reviews.llvm.org/D54865

llvm-svn: 347538

[clang-tidy] Don't generate incorrect fixes for class with deleted copy constructor in smart_ptr check.

Summary:
The fix for aggregate initialization (`std::make_unique<Foo>(Foo {1, 2})` needs
to see Foo copy constructor, otherwise we will have a compiler error. So we
only emit the check warning.

Reviewers: JonasToth, aaron.ballman

Subscribers: xazax.hun, cfe-commits

Differential Revision: https://reviews.llvm.org/D54745

llvm-svn: 347537

We had a proper error reporting, but no test cases.

llvm-svn: 347536

LLD reports an error in this case, but we had no test.

llvm-svn: 347535

This reverts commits r347532. Forget add the option 
-mtriple powerpc64-unknown-linux-gnu. So other platform is error except
for PowerPC.

llvm-svn: 347534

[X86] Add test cases to show bad type legalization of fptosi/fptosui v16f32->v16i8 and v8f64->v8i16 on pre-AVX512 targets.

When splitting the v16f32/v8f64 result type, type legalization will try to promote the integer result type before a concat and an explicit truncate. But for the fptoui test case this is particularly bad since fptoui isn't supported on X86 until AVX512. We could use an fptosi since the result range would fit in a signed 32-bit value, but the generic type legalization doesn't do that transformation when splitting. It does do this when promoting.

llvm-svn: 347533

Summary:
There are 4 instructions which have Inconsistent ImmMustBeMultipleOf in the
function PPCInstrInfo::instrHasImmForm, they are LFS, LFD, STFS, STFD.
These four instructions should set the ImmMustBeMultipleOf to 1 instead of 4.

Reviewed By: nemanjai

Differential Revision: https://reviews.llvm.org/D54738

llvm-svn: 347532

if a __builtin_constant_p() is a part of a constexpr.

llvm-svn: 347531

[Support/FileSystem] Add sub-second precision for atime/mtime of sys::fs::file_status on unix platforms

Summary:
getLastAccessedTime() and getLastModificationTime() provided times in nanoseconds but with only 1 second resolution, even when the underlying file system could provide more precise times than that.
These changes add sub-second precision for unix platforms that support improved precision.

Also add some comments to make sure people are aware that the resolution of times can vary across different file systems.

Reviewers: labath, zturner, aaron.ballman, kristina

Reviewed By: aaron.ballman, kristina

Subscribers: lebedev.ri, mgorny, kristina, llvm-commits

Differential Revision: https://reviews.llvm.org/D54826

llvm-svn: 347530

Use range-based for loops
Use XStr.compare(YStr) < 0
Format misaligned code

llvm-svn: 347529

llvm-svn: 347528

This was originally part of:
D50924

and should resolve PR37387:
https://bugs.llvm.org/show_bug.cgi?id=37387

...but it was reverted because some bots using a gcc host compiler 
would crash for unknown reasons with this included in the patch. 
Trying again now to see if that's still a problem.

llvm-svn: 347527

This should likely be adjusted to limit this transform
further, but these diffs should be clear wins.

If we have blendv/conditional move, then we should assume 
those are cheap ops. The loads become independent of the
compare, so those can be speculated before we need to use 
the values in the blend/mov.

llvm-svn: 347526

There are many options here depending on subtarget,
but we are uniformly relying on a transform that was 
driven by performance for a 32-bit SSE2 target in 2009.

Note: The same motivation was apparently used to do this 
transform for *all* targets, so non-x86 may want to look
at this too.

llvm-svn: 347525

OriginalOp of a Predicate refers to the original IR value,
before renaming. While solving in IPSCCP, we have to use
the operand of the ssa_copy instead, to avoid missing
updates for nested conditions on the same IR value.

Fixes PR39772.

llvm-svn: 347524

rL347502 moved the null sibling, so we should group all of these
together. I'm not sure why these aren't methods of the SDValue
class itself, but that's another patch if that's possible.

llvm-svn: 347523

By default, llvm-mca conservatively assumes that a register operand from the
variadic sequence is both a register read and a register write.  That is because
MCInstrDesc doesn't describe extra variadic operands; we don't have enough
dataflow information to tell which register operands from the variadic sequence
is a definition, and which is a use instead.

However, if a variadic instruction is flagged 'mayStore' (but not 'mayLoad'),
and it has no 'unmodeledSideEffects', then llvm-mca (very) optimistically
assumes that any register operand in the variadic sequence is a register read
only. Conversely, if a variadic instruction is marked as 'mayLoad' (but not
'mayStore'), and it has no 'unmodeledSideEffects', then llvm-mca optimistically
assumes that any extra register operand is a register definition only.
These assumptions work quite well for variadic load/store multiple instructions
defined by the ARM backend.

llvm-svn: 347522

llvm-svn: 347521

Removed the uses of the allOf() matcher inside node matchers that are implicit
allOf(). Replaced uses of allOf() with the explicit node matcher where it makes
matchers more readable. Replace anyOf(hasName(), hasName(), ...) with the more
efficient and readable hasAnyName().

llvm-svn: 347520

llvm-svn: 347519

[X86] Synchronize a macro in getAvailableFeatures in Host.cpp with the same macro in compiler-rt to fix a negative shift amount warning.

llvm-svn: 347518

llvm-svn: 347517

[X86][compiler-rt] Attempt to fix a warning about a shift amount being negative in a macro expansion.

llvm-svn: 347516

Support funnel shifts in InstCombine demanded bits simplification.
If the shift amount is constant, we can determine both the demanded
bits of the operands, as well as the known bits of the result.

If one of the operands has no demanded bits, it will be replaced
by undef and the funnel shift will be simplified into a simple shift
due to the simplifications added in D54778.

Differential Revision: https://reviews.llvm.org/D54869

llvm-svn: 347515

llvm-svn: 347514

This checker implements a solution to the "INT50-CPP. Do not cast to an
out-of-range enumeration value" rule [1].
It lands in alpha for now, and a number of followup patches are planned in order
to enable it by default.

[1] https://www.securecoding.cert.org/confluence/display/cplusplus/INT50-CPP.+Do+not+cast+to+an+out-of-range+enumeration+value

Patch by: Endre Fülöp and Alexander Zaitsev!

Differential Revision: https://reviews.llvm.org/D33672

llvm-svn: 347513