[SCCP] Use the appropriate helper function. NFCI.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289406 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][AVX512] Add missing patterns for broadcast fallback in case load node has multiple uses (for v4i64 and v4f64).

When the load node which the broadcast instruction broadcasts has multiple uses, it cannot be folded.
A fallback pattern is added to catch these cases and provide another solution.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289404 91177308-0d34-0410-b5e6-96231b3b80d8

[TBAA] Don't generate invalid TBAA when merging nodes

Summary:
Fix a corner case in `MDNode::getMostGenericTBAA` where we can sometimes
generate invalid TBAA metadata.

Reviewers: chandlerc, hfinkel, mehdi_amini, manmanren

Subscribers: mcrosier, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289403 91177308-0d34-0410-b5e6-96231b3b80d8

[Verifier] Add verification for TBAA metadata

Summary:
This change adds some verification in the IR verifier around struct path
TBAA metadata.

Other than some basic sanity checks (e.g. we get constant integers where
we expect constant integers), this checks:

 - That by the time an struct access tuple `(base-type, offset)` is
   "reduced" to a scalar base type, the offset is `0`.  For instance, in
   C++ you can't start from, say `("struct-a", 16)`, and end up with
   `("int", 4)` -- by the time the base type is `"int"`, the offset
   better be zero.  In particular, a variant of this invariant is needed
   for `llvm::getMostGenericTBAA` to be correct.

 - That there are no cycles in a struct path.

 - That struct type nodes have their offsets listed in an ascending
   order.

 - That when generating the struct access path, you eventually reach the
   access type listed in the tbaa tag node.

Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren

Subscribers: mcrosier, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289402 91177308-0d34-0410-b5e6-96231b3b80d8

[Constants] don't die processing non-ConstantInt GEP indices in isGEPWithNoNotionalOverIndexing() (PR31262)

This should fix:
https://llvm.org/bugs/show_bug.cgi?id=31262

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289401 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][AVX512] Add target shuffle test showing missing PSHUFPD combine.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289400 91177308-0d34-0410-b5e6-96231b3b80d8

instr-combiner: sum up all latencies of the transformed instructions

We have found that -- when the selected subarchitecture has a scheduling model
and we are not optimizing for size -- the machine-instruction combiner uses a
too-simple algorithm to compute the cost of one of the two alternatives [before
and after running a combining pass on a section of code], and therefor it throws
away the combination results too often.

This fix has the potential to help any ISA with the potential to combine
instructions and for which at least one subarchitecture has a scheduling model.
As of now, this is only known to definitely affect AArch64 subarchitectures with
a scheduling model.

Regression tested on AMD64/GNU-Linux, new test case tested to fail on an
unpatched compiler and pass on a patched compiler.

Patch by Abe Skolnik and Sebastian Pop.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289399 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][XOP] Add target shuffle tests showing missing PSHUFPD combine.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289398 91177308-0d34-0410-b5e6-96231b3b80d8

[SCEVExpander] Explicitly expand AddRec starts into loop preheader

This is NFC today, but won't be once D27216 (or an equivalent patch) is
in.

This change fixes a design problem in SCEVExpander -- it relied on a
hoisting optimization to generate correct code for add recurrences.
This meant changing the hoisting optimization to not kick in under
certain circumstances (to avoid speculating faulting instructions, say)
would break correctness.

The fix is to make the correctness requirements explicit, and have it
not rely on the hoisting optimization for correctness.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289397 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Regcall - Adding support for mask types

Regcall calling convention passes mask types arguments in x86 GPR registers.
The review includes the changes required in order to support v32i1, v16i1 and v8i1.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289383 91177308-0d34-0410-b5e6-96231b3b80d8

[FileCheck] Re-implement the logic to find each check prefix in the
check file to not be unreasonably slow in the face of multiple check
prefixes.

The previous logic would repeatedly scan potentially large portions of
the check file looking for alternative prefixes. In the worst case this
would scan most of the file looking for a rare prefix between every
single occurance of a common prefix. Even if we bounded the scan, this
would do bad things if the order of the prefixes was "unlucky" and the
distant prefix was scanned for first.

None of this is necessary. It is straightforward to build a state
machine that recognizes the first, longest of the set of alternative
prefixes. That is in fact exactly whan a regular expression does.

This patch builds a regular expression once for the set of prefixes and
then uses it to search incrementally for the next prefix. This requires
some threading of state but actually makes the code dramatically
simpler. I've also added a big comment describing the algorithm as it
was not at all obvious to me when I started.

With this patch, several previously pathological test cases in
test/CodeGen/X86 are 5x and more faster. Overall, running all tests
under test/CodeGen/X86 uses 10% less CPU after this, and because all the
slowest tests were hitting this, finishes in 40% less wall time on my
system (going from just over 5.38s to just over 3.23s) on a release
build! This patch substantially improves the time of all 7 X86 tests
that were in the top 20 reported by --time-tests, 5 of them are
completely off the list and the remaining 2 are much lower. (Sadly, the
new tests on the list include 2 new X86 ones that are slow for unrelated
reasons, so the count stays at 4 of the top 20.)

It isn't clear how much this helps debug builds in aggregate in part
because of the noise, but it again makes mane of the slowest x86 tests
significantly faster (10% or more improvement).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289382 91177308-0d34-0410-b5e6-96231b3b80d8

[FileCheck] Remove a parameter that was simply always set to
a commandline flag and test the flag directly. NFC.

If we ever need this generality it can be added back.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289381 91177308-0d34-0410-b5e6-96231b3b80d8

[FileCheck] Clean up doxygen comments throughout. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289380 91177308-0d34-0410-b5e6-96231b3b80d8

[FileCheck] Run clang-format over this code. NFC.

This fixes one formatting goof I left in my previous commit and *many*
other inconsistencies.

I'm planning to make substantial changes here and so wanted to get to
a clean baseline.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289379 91177308-0d34-0410-b5e6-96231b3b80d8

Refactor FileCheck some to reduce memory allocation and copying. Also
make some readability improvements.

Both the check file and input file have to be fully buffered to
normalize their whitespace. But previously this would be done in a stack
SmallString and then copied into a heap allocated MemoryBuffer. That
seems pretty wasteful, especially for something like FileCheck where
there are only ever two such entities.

This just rearranges the code so that we can keep the canonicalized
buffers on the stack of the main function, use reasonably large stack
buffers to reduce allocation. A rough estimate seems to show that about
80% of LLVM's .ll and .s files will fit into a 4k buffer, so this should
completely avoid heap allocation for the buffer in those cases. My
system's malloc is fast enough that the allocations don't directly show
up in timings. However, on some very slow test cases, this saves 1% - 2%
by avoiding the copy into the heap allocated buffer.

This also splits out the code which checks the input into a helper much
like the code to build the checks as that made the code much more
readable to me. Nit picks and suggestions welcome here. It has really
exposed a *bunch* of stuff that could be cleaned up though, so I'm
probably going to go and spring clean all of this code as I have more
changes coming to speed things up.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289378 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][InstCombine] Add support for scalar FMA intrinsics to SimplifyDemandedVectorElts.

This teaches SimplifyDemandedElts that the FMA can be removed if the lower element isn't used. It also teaches it that if upper elements of the first operand aren't used then we can simplify them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289377 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][InstCombine] Add the test cases for r289370, r289371, and r289372.

I forgot to add the new files before commiting.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289374 91177308-0d34-0410-b5e6-96231b3b80d8

Tweak the core loop in StringRef::find to avoid calling memcmp on every
iteration.

Instead, load the byte at the needle length, compare it directly, and
save it to use in the lookup table of lengths we can skip forward.

I also added an annotation to expect that the comparison fails so that
the loop gets laid out contiguously without the call to memcpy (and the
substantial register shuffling that the ABI requires of that call).

Finally, because this behaves especially badly with a needle length of
one (by calling memcmp with a zero length) special case that to directly
call memchr, which is what we should have been doing anyways.

This was motivated by the fact that there are a large number of test
cases in 'check-llvm' where FileCheck's performance is dominated by
calls to StringRef::find (in a release, no-asserts build). I'm working
on patches to generally improve matters there, but this alone was worth
a 12.5% improvement in one test case where FileCheck spent 92% of its
time in this routine.

I experimented a bunch with different minor variations on this theme,
for example setting the pointer *at* the last byte and indexing
backwards for the call to memcmp. That didn't improve anything on this
version and seemed more complex. I also tried other things to make the
loop flow more nicely and none worked. =/ It is a bit unfortunate, the
generated code here remains pretty gross, but I don't see any obvious
ways to improve it. At this point, most of my ideas would be really
elaborate:

1) While the remainder of the string is long enough, we could load
   a 16-byte or 32-byte vector at the address of the last byte and use
   palignr to rotate that and check the first 15- or 31-bytes at the
   front of the next segment, essentially pre-loading the first several
   bytes of the next iteration so we could quickly detect a mismatch in
   those bytes without an additional memory access. Down side would be
   the code complexity, having a fallback loop, and likely misaligned
   vector load. Plus it would make the common case of the last byte not
   matching somewhat slower (need some extraction from a vector).
2) While we have space, we could do an aligned load of a 16- or 32-byte
   vector that *contains* the end byte, and use any peceding bytes to
   have a more precise "no" test, and any subsequent bytes could be
   saved for the next iteration. This remove any unaligned load penalty,
   but still requires us to pay the overhead of vector extraction for
   the cases where we didn't need to do anything other than load and
   compare the last byte.
3) Try to walk from the last byte in a way that is more friendly to
   cache and/or memory pre-fetcher considering we have to poke the last
   byte anyways.

No idea if any of these are really worth pursuing though. They all seem
somewhat unlikely to yield big wins in practice and to be a lot of work
and complexity. So I settled here, which at least seems like a strict
improvement over the previous version.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289373 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][InstCombine] Teach InstCombineCalls to simplify demanded elements for scalar FMA intrinsics.

These intrinsics don't read the upper bits of their second and third inputs so we can try to simplify them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289372 91177308-0d34-0410-b5e6-96231b3b80d8

[AVX-512][InstCombine] Teach InstCombineCalls how to simplify demanded for scalar cmp intrinsics with masking and rounding.

These intrinsics don't read the upper elements of their first and second input. These are slightly different the the SSE version which does use the upper bits of its first element as passthru bits since the result goes to an XMM register. For AVX-512 the result goes to a mask register instead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289371 91177308-0d34-0410-b5e6-96231b3b80d8

[AVX-512][InstCombine] Teach InstCombineCalls how to simplify demanded elements for scalar add,div,mul,sub,max,min intrinsics with masking and rounding.

These intrinsics don't read the upper bits of their second input. And the third input is the passthru for masking and that only uses the lower element as well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289370 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Add calling convention CodeGen tests

This adds CodeGen tests for the AVR C calling convention.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289369 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] don't depend on time in a test

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289368 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Add a test to validate a simple 'blinking led' program

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289362 91177308-0d34-0410-b5e6-96231b3b80d8

[AVX-512][InstCombine] Add 512-bit vpermilvar intrinsics to InstCombineCalls to match 128 and 256-bit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289354 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Fix a comment to say 'an FMA' instead of 'a FMA'. NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289352 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Remove masking from 512-bit VPERMIL intrinsics in preparation for being able to constant fold them in InstCombineCalls like we do for 128/256-bit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289350 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Fix a signed vs unsigned compiler warning

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289349 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][InstCombine] Teach InstCombineCalls to turn pshufb intrinsic into a shufflevector if the indices are constant.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289348 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Remove incorrect comment

This should've been removed in r289323.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289346 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Remove masking from 512-bit PSHUFB intrinsics in preparation for being able to constant fold it in InstCombineCalls like we do for 128/256-bit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289344 91177308-0d34-0410-b5e6-96231b3b80d8

[InstCombine] add helper for shift-by-shift folds; NFCI

These are currently limited to integer types, but we should
be able to extend to splat vectors and possibly general vectors.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289343 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][SSE] Add tests for sign extended vXi64 multiplication

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289342 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][SSE] Ensure UNPCK inputs are a consistent value type in LowerHorizontalByteSum

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289341 91177308-0d34-0410-b5e6-96231b3b80d8

[AVX-512] Remove 128/256 masked vpermil instrinsics and autoupgrade to a select around the unmasked avx1 intrinsics.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289340 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][IR] Move the autoupgrading of store intrinsics out of the main nested if/else chain. This should buy a little more time against the MSVC limit mentioned in PR31034.

The handlers for stores all return at the end of their block so they can be picked off early.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289339 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Fix asan errors when folding operands

This was failing when trying to fold immediates into operand 1 of a
phi, which only has one statically known operand.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289337 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][SSE] Move ZeroVector creation into the shuffle pattern case where its actually used.

Also fix the ZeroVector's type - I've no idea how this hasn't caused problems........

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289336 91177308-0d34-0410-b5e6-96231b3b80d8

[AVX-512] Add support for lowering (v2i64 (fp_to_sint (v2f32))) to vcvttps2uqq when AVX512DQ and AVX512VL are available.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289335 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Clarify indentation. NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289334 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Combine LowerFP_TO_SINT and LowerFP_TO_UINT. They only differ by a single boolean flag passed to a helper function. Just check the opcode and create the flag.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289333 91177308-0d34-0410-b5e6-96231b3b80d8

[InstSimplify] improve function name; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289332 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Eliminate else-after-return. NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289331 91177308-0d34-0410-b5e6-96231b3b80d8

[SelectionDAG] Add ability for computeKnownBits to peek through bitcasts from 'large element' scalar/vector to 'small element' vector.

Extension to D27129 which already supported bitcasts from 'small element' vector to 'large element' scalar/vector types.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289329 91177308-0d34-0410-b5e6-96231b3b80d8

[X86][XOP] Add permil2ps buildvector combine test

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289327 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Add a stub README file

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289326 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Fix and clean up the inline assembly tests

There was a bug where we would hit an assertion if 'Q' was used as a
constraint.

I also removed hardcoded register names to prefer regexes so the tests
don't break when the register allocator changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289325 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Explicitly set the target in all CodeGen tests

This seems to have caused failures on the buildbot.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289324 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Fix an inline asm assertion which would always trigger

It looks like some time in the past, constraint codes were changed from
chars being passed around to enums.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289323 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Use the register scavenger when expanding 'LDDW' instructions

Summary: This gets rid of the hardcoded 'r0' that was used previously.

Reviewers: asl

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289322 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Support stores to undefined pointers

This would previously trigger an assertion error in AVRISelDAGToDAG.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289321 91177308-0d34-0410-b5e6-96231b3b80d8

[PM] Further broaden this test's regex as both the CGSCC and Function
inner AM proxies are now being rendered differently.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289319 91177308-0d34-0410-b5e6-96231b3b80d8

[PM] Try to support the new spelling of one of the proxy names that are
showing up on the build bots.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289318 91177308-0d34-0410-b5e6-96231b3b80d8

[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.

Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.

The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.

The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.

However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.

An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.

Reviewers: jlebar

Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289317 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Use X86ISD::CVTTP2SI and X86ISD::CVTTP2UI for lowering 128-bit cvttps2qq and cvttps2uqq intrinsics since there is a mismatch between number of input and output elements.

Ideally ISD::FP_TO_SINT and ISD::FP_TO_UINT would only be used for cases with the same number of input and output elements.

Similar things have already been done for other convert intrinsics.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289316 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Fix a bunch of incorrect assertion messages

These should've been checking whether the immediate is a 6-bit unsigned
integer.

If the immediate was '63', this would cause an assertion error which
shouldn't have occurred.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289315 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] test cleanup (3)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289314 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] test cleanup (2)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289313 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] test cleanup

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289312 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] switch all libFuzzer tests to use -fsanitize-coverage=trace-pc-guard. Support for the previosly used instrumentation will be removed in the following changes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289311 91177308-0d34-0410-b5e6-96231b3b80d8

[libFuzzer] use __sanitizer_get_module_and_offset_for_pc to get the module name while printing the coverage

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289310 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Fix AMDGPUPromoteAlloca breaking addrspacecasts

The users of the addrspacecast were having their types incorrectly
changed, producing invalid bitcasts between address spaces.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289307 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Fix handling of 16-bit immediates

Since 32-bit instructions with 32-bit input immediate behavior
are used to materialize 16-bit constants in 32-bit registers
for 16-bit instructions, determining the legality based
on the size is incorrect. Change operands to have the size
specified in the type.

Also adds a workaround for a disassembler bug that
produces an immediate MCOperand for an operand that
is supposed to be OPERAND_REGISTER.

The assembler appears to accept out of bounds immediates and
truncates them, but this seems to be an issue for 32-bit
already.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289306 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Fix vintrp disassembly

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289292 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Change vintrp printing to better match sc

Some of the immediates need to be printed differently
eventually.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289291 91177308-0d34-0410-b5e6-96231b3b80d8

Bigger-hammer REQUIRES to fix Windows bot.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289288 91177308-0d34-0410-b5e6-96231b3b80d8

[AMDGPU, PowerPC, TableGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289282 91177308-0d34-0410-b5e6-96231b3b80d8

Speculative REQUIRES to fix Windows bot.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289281 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Regenerate test

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289279 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Cleanup checks in sext_inreg test

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289272 91177308-0d34-0410-b5e6-96231b3b80d8

Fix LLVM's use of DW_OP_bit_piece in DWARF expressions.

LLVM's use of DW_OP_bit_piece is incorrect and a based on a
misunderstanding of the wording in the DWARF specification. The offset
argument of DW_OP_bit_piece refers to the offset into the location
that is on the top of the DWARF expression stack, and not an offset
into the source variable. This has since also been clarified in the
DWARF specification.

This patch fixes all uses of DW_OP_bit_piece to emit the correct
offset and simplifies the DwarfExpression class to semi-automaticaly
emit empty DW_OP_pieces to adjust the offset of the source variable,
thus simplifying the code using DwarfExpression.

While this is an incompatible bugfix, in practice I don't expect this
to be much of a problem since LLVM's old interpretation and the
correct interpretation of DW_OP_bit_piece differ only when there are
gaps in the fragmented locations of the described variables or if
individual fragments are smaller than a byte. LLDB at least won't
interpret locations with gaps in them because is has no way to present
undefined bits in a variable, and there is a high probability that an
old-form expression will be malformed when interpreted correctly,
because the DW_OP_bit_piece offset will be outside of the location at
the top of the stack.

As a nice side-effect, this patch enables us to use a more efficient
encoding for subregisters: In order to express a sub-register at a
non-zero offset we now use a DW_OP_bit_piece instead of shifting the
value into place manually.

This patch also adds missing test coverage for code paths that weren't
exercised before.

<rdar://problem/29335809>
Differential Revision: https://reviews.llvm.org/D27550

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289266 91177308-0d34-0410-b5e6-96231b3b80d8

Add README describing the intention of test/CodeGen/MIR

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289265 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU/SI: Remove XNACK feature from CI

Summary: CI doesn't have XNACK.

Reviewers: tstellarAMD

Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289263 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU/SI: Don't reserve XNACK when it's disabled

Summary:
This frees 2 additional scalar registers.

These are results from all of my 3 patches combined:

  Polaris:
    Spilled SGPRs: 2231 -> 1517 (-32.00 %)

  Tonga:
    Spilled SGPRs: 3829 -> 2608 (-31.89 %)
    Spilled VGPRs: 100 -> 84 (-16.00 %)

  Tonga even spills SGPRs via VGPRs to scratch. That's a compute shader
  limited to 64 VGPRs.

Reviewers: tstellarAMD

Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289262 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU/SI: Don't reserve FLAT_SCR on non-HSA targets & without stack objects

Summary: This frees 2 scalar registers.

Reviewers: tstellarAMD

Subscribers: qcolombet, arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289261 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU/SI: Allow using SGPRs 96-101 on VI

Summary:
There is no point in setting SGPRS=104, because VI allocates SGPRs
in multiples of 16, so 104 -> 112. That enables us to use all 102 SGPRs
for general purposes.

Reviewers: tstellarAMD

Subscribers: qcolombet, arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289260 91177308-0d34-0410-b5e6-96231b3b80d8

Remove /Zc:sizedDealloc- from the MSVC build

According to the connect bug
(https://connect.microsoft.com/VisualStudio/feedback/details/1351894),
this was only necessary with pre-release versions of MSVC 2015.

Fixes PR23513

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289257 91177308-0d34-0410-b5e6-96231b3b80d8

[DWARF] Suppress .loc directives from CFI instructions

Like DBG_VALUE, these emit nothing to the .text section, and sometimes
have no source location specified.  Just ignore them.

Differential Revision: http://reviews.llvm.org/D27492

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289256 91177308-0d34-0410-b5e6-96231b3b80d8

Move .mir tests to appropriate directories

test/CodeGen/MIR should contain tests that intent to test the MIR
printing or parsing. Tests that test something else should be in
test/CodeGen/TargetName even when they are written in .mir.

As a rule of thumb, only tests using "llc -run-pass none" should be in
test/CodeGen/MIR.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289254 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Fix isTypeDesirableForOp for i16

This should do nothing for targets without i16.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289235 91177308-0d34-0410-b5e6-96231b3b80d8

[SelectionDAG] Add knownbits support for EXTRACT_VECTOR_ELT opcodes (REAPPLIED)

Reapplied with fix for PR31323 - X86 SSE2 vXi16 multiplies for illegal types were creating CONCAT_VECTORS nodes with vector inputs that might not total the number of elements in the result type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289232 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Fix i128 mul

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289231 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Allow TBA, TMA, TTMP* registers with SMEM instructions

Fixes assembler regressions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289230 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU: Clean up instruction bits

Sort the instruction bits by type and make sure there is one
for each format.

Also cleanup namespaces.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289229 91177308-0d34-0410-b5e6-96231b3b80d8

[PPC] Add intrinsics for vector extract word and vector insert word.

Revision: https://reviews.llvm.org/D26547

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289227 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled."

This reverts commit r289221 which appears to be triggering an assertion

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289226 91177308-0d34-0410-b5e6-96231b3b80d8

In visitSTORE, always use FindBetterChain, rather than only when UseAA is enabled.

Retrying after fixing overly aggressive load-store forwarding optimization.

Simplify Consecutive Merge Store Candidate Search

Now that address aliasing is much less conservative, push through
simplified store merging search which only checks for parallel stores
through the chain subgraph. This is cleaner as the separation of
non-interfering loads/stores from the store-merging logic.

Whem merging stores, search up the chain through a single load, and
finds all possible stores by looking down from through a load and a
TokenFactor to all stores visited. This improves the quality of the
output SelectionDAG and generally the output CodeGen (with some
exceptions).

Additional Minor Changes:

   1. Finishes removing unused AliasLoad code
   2. Unifies the the chain aggregation in the merged stores across
      code paths
   3. Re-add the Store node to the worklist after calling
      SimplifyDemandedBits.
   4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is
      arbitrary, but seemed sufficient to not cause regressions in
      tests.

This finishes the change Matt Arsenault started in r246307 and
jyknight's original patch.

Many tests required some changes as memory operations are now
reorderable. Some tests relying on the order were changed to use
volatile memory operations

Noteworthy tests:

    CodeGen/AArch64/argument-blocks.ll -
      It's not entirely clear what the test_varargs_stackalign test is
      supposed to be asserting, but the new code looks right.

    CodeGen/AArch64/arm64-memset-inline.lli -
    CodeGen/AArch64/arm64-stur.ll -
    CodeGen/ARM/memset-inline.ll -

      The backend now generates *worse* code due to store merging
      succeeding, as we do do a 16-byte constant-zero store efficiently.

    CodeGen/AArch64/merge-store.ll -
      Improved, but there still seems to be an extraneous vector insert
      from an element to itself?

    CodeGen/PowerPC/ppc64-align-long-double.ll -
      Worse code emitted in this case, due to the improved store->load
      forwarding.

    CodeGen/X86/dag-merge-fast-accesses.ll -
    CodeGen/X86/MergeConsecutiveStores.ll -
    CodeGen/X86/stores-merging.ll -
    CodeGen/Mips/load-store-left-right.ll -
      Restored correct merging of non-aligned stores

    CodeGen/AMDGPU/promote-alloca-stored-pointer-value.ll -
      Improved. Correctly merges buffer_store_dword calls

    CodeGen/AMDGPU/si-triv-disjoint-mem-access.ll -
      Improved. Sidesteps loading a stored value and
      merges two stores

    CodeGen/X86/pr18023.ll -
      This test has been removed, as it was asserting incorrect
      behavior. Non-volatile stores *CAN* be moved past volatile loads,
      and now are.

    CodeGen/X86/vector-idiv.ll -
    CodeGen/X86/vector-lzcnt-128.ll -
      It's basically impossible to tell what these tests are actually
      testing. But, looks like the code got better due to the memory
      operations being recognized as non-aliasing.

    CodeGen/X86/win32-eh.ll -
      Both loads of the securitycookie are now merged.

Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle

Subscribers: wdng, nhaehnle, nemanjai, arsenm, weimingz, niravd, RKSimon, aemerson, qcolombet, dsanders, resistor, tstellarAMD, t.p.northover, spatel

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289221 91177308-0d34-0410-b5e6-96231b3b80d8

Use SelectionDAG.getSplatBuildVector helper. NFCI.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289220 91177308-0d34-0410-b5e6-96231b3b80d8

AMDGPU/SI: Don't mark VINTRP instructions as mayLoad

Summary:
These instructions technically do read from memory, but the memory
is considered to be out of bounds for normal load/store instructions.

shader-db stats:

SGPRS: 1416075 -> 1413323 (-0.19 %)
VGPRS: 867413 -> 863935 (-0.40 %)
Spilled SGPRs: 1409 -> 1354 (-3.90 %)
Spilled VGPRs: 63 -> 63 (0.00 %)
Private memory VGPRs: 880 -> 880 (0.00 %)
Scratch size: 2648 -> 2632 (-0.60 %) dwords per thread
Code Size: 37889052 -> 37897340 (0.02 %) bytes
LDS: 2147 -> 2147 (0.00 %) blocks
Max Waves: 279243 -> 280369 (0.40 %)
Wait states: 0 -> 0 (0.00 %)

Reviewers: nhaehnle, mareko, arsenm

Subscribers: kzhuravl, wdng, yaxunl, tony-tye

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289219 91177308-0d34-0410-b5e6-96231b3b80d8

[SelectionDAG] Use SelectionDAG.getBuildVector helper. NFCI.

Makes interception of BUILD_VECTOR creation easier for debugging.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289218 91177308-0d34-0410-b5e6-96231b3b80d8

[SCEVExpander] Remove \brief, reflow comments; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289216 91177308-0d34-0410-b5e6-96231b3b80d8

[SCEVExpander] Use llvm data structures; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289215 91177308-0d34-0410-b5e6-96231b3b80d8

[SelectionDAG] Add additional checks to CONCAT_VECTORS creation

Part of the work for PR31323 - add extra asserts checking that the input vectors are of consistent type and result in the correct number of vector elements.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289214 91177308-0d34-0410-b5e6-96231b3b80d8

Plug another leak in the DWARF unittests, DIEInlineStrings are never destroyed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289208 91177308-0d34-0410-b5e6-96231b3b80d8

Fix memory leak in unit test.

The StringPool entries are destroyed with the allocator, the string pool
itself is not.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289207 91177308-0d34-0410-b5e6-96231b3b80d8

llvm/test/Object/archive-thin-create.test: Make sure that %t is empty to stabilize the test.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289202 91177308-0d34-0410-b5e6-96231b3b80d8

[AVR] Remove a set of redundant tests

This fixes the build.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289201 91177308-0d34-0410-b5e6-96231b3b80d8

[SelectionDAG] Add partial BITCAST support to computeKnownBits

Adds support for bitcasting a little endian 'small element' vector to 'large element' scalar/vector (e.g. v16i8 to v4i32 or v2i32 to i64), which is required for PR30845. We extract the knownbits for each 'small element' part and concatenate the results together.

We can add support for big endian and 'large element' scalar/vector to 'small element' vector bitcasting once we have test cases for them.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289200 91177308-0d34-0410-b5e6-96231b3b80d8

Update Doxygen comment in StringSaver (NFC)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289196 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "[SelectionDAG] Add knownbits support for EXTRACT_VECTOR_ELT opcodes"

This reverts commit r288916 as it is currently causing a crasher in
Halide. Reproducer on llvm.org/PR31323. While it might be that halide is
generating invalid IR, llc shouldn't crash.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289194 91177308-0d34-0410-b5e6-96231b3b80d8