AMDGPU/SILoadStoreOptimizer: Make some functions const

Reviewers: arsenm, pendingchaos, rampitec

Reviewed By: rampitec

Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367517

recommit:[PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store

In PowerPC, there is instruction to load vector in big endian element order when it's in little endian target.
So we can combine vector load + reverse into big endian load to eliminate the swap instruction.
Also combine vector reverse + store into big endian store.

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

llvm-svn: 367516

[ELF] Fix finding locations in messages for undefined hidden symbols.

Previously, when `--vs-diagnostics` was used, the linker printed
something like

  hidden(undef.s): error: undefined hidden symbol: foo
  >>> referenced by undef.s:15

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

llvm-svn: 367515

AMDGPU/GlobalISel: fix inst-select-load-local.mir in -DLLVM_ENABLE_ASSERTIONS=off builds after r367498

llvm-svn: 367514

AMDGPU/GlobalISel: Fix flat load/store of pointer types

llvm-svn: 367513

AMDGPU/GlobalISel: Remove manual store select code

This regresses the weird types that are newly treated as legal load
types, but fixes incorrectly using flat instrucions on SI.

llvm-svn: 367512

AMDGPU/GlobalISel: Select local atomic cmpxchg

llvm-svn: 367511

Revert "[NFC] Remove obsolete LLVM_GNUC_PREREQ"

The bots are sad, looks like GCC doesn't always have __has_builtin. I'll need to
modify the logic a bit.

llvm-svn: 367510

AMDGPU/GlobalISel: Handle G_ATOMICRMW_FADD

llvm-svn: 367509

[NFC] Remove obsolete LLVM_GNUC_PREREQ

The current minimum GCC version is 4.8 (soon to be 5.1), we there don't need to check for older versions. While I'm around Compiler.h, also update some of the doxygen comment.

llvm-svn: 367508

AMDGPU/GlobalISel: Allow selection of DS atomicrmw

llvm-svn: 367507

AMDGPU: Start redefining atomic PatFrags

Start migrating to a form that will be compatible with the global isel
emitter. Also should fix some overly lax checks on the memory type,
which allowed mis-selecting some illegal atomics.

llvm-svn: 367506

AMDGPU: Correct FP atomic patterns

These need to use an fadd, not an add. Also make the noret part clear
in the name.

llvm-svn: 367505

AMDGPU/GlobalISel: Select simple local stores

llvm-svn: 367504

GlobalISel: moreElementsVector for G_LOAD/G_STORE

AMDGPU change and test is a placeholder until a future patch with
complete handling.

llvm-svn: 367503

[Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

Fix one test case for it to be system-independent.

llvm-svn: 367502

Create unique, but identically-named ELF sections for explicitly-sectioned functions and globals when using -function-sections and -data-sections.

This allows functions and globals to to be reordered later in the linking phase
(using the -symbol-ordering-file) even though reordering will be limited to
the scope of the explicit section.

Patch by Rahman Lavaee!

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

llvm-svn: 367501

Reapply "AMDGPU: Split block for si_end_cf"

This reverts commit r359363, reapplying r357634

llvm-svn: 367500

Fix a release-only build warning triggered by rL367485

llvm-svn: 367499

AMDGPU/GlobalISel: Select local loads

llvm-svn: 367498

[Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

Issue an warning when the code tries to do an implicit int -> float
conversion, where the float type ha a narrower significant than the
float type.

The new warning is controlled by flag -Wimplicit-int-float-conversion,
under -Wimplicit-float-conversion and -Wconversion. It is also silenced
when c++11 narrowing warning is issued.

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

llvm-svn: 367497

Revert "[MS] Emit S_HEAPALLOCSITE debug info in Selection DAG" and
and partial fix.
Causes windows buildbot errors.

This reverts commit 6e65c34523963094acd0d6c94a5f5c64b32fe6aa and
53da7ca94343166ac68aef81db0398932fc258bb.

llvm-svn: 367496

Fix build when both gtest death tests and LLVM_NODISCARD are available.

llvm-svn: 367495

[Reproducers] Force replay in synchronous mode.

Replaying a reproducer in asynchronous mode never makes sense. This
patch disables asynchronous mode during replay.

Differential revision: https://reviews.llvm.org/D65547

llvm-svn: 367494

compiler-rt: Try to appease lint script.

A bot complains:

/b/sanitizer-x86_64-linux-autoconf/build/llvm/projects/compiler-rt/lib/sanitizer_common/tests/malloc_stress_transfer_test.cpp:2:  Streams are highly discouraged.  [readability/streams] [3]
/b/sanitizer-x86_64-linux-autoconf/build/llvm/projects/compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp:11:  Streams are highly discouraged.  [readability/streams] [3]
lib/CMakeFiles/SanitizerLintCheck.dir/build.make:57: recipe for target 'lib/CMakeFiles/SanitizerLintCheck' failed

I do not know why this apparently wasn't a problem when the files
had extension .cc.

llvm-svn: 367493

[ARM] Lower "(x<<c) > 0x80000000U" to "lsls" on Thumb1.

This is extremely specific, but saves three instructions when it's
legal.  I don't think the code can be usefully generalized.

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

llvm-svn: 367492

[ARM] Transform compare of masked value to shift on Thumb1.

Thumb1 has very limited immediate modes, so turning an "and" into a
shift can save multiple instructions.

It's possible to simplify the generated code for test2 and test3 in
cmp-and-fold.ll a little more, but I'll implement that as a followup.

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

llvm-svn: 367491

[ConstExprPreter] Overflow-detecting methods use GCC or clang builtins

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

llvm-svn: 367490

[ScalarizeMaskedMemIntrin] Bitcast the mask to the scalar domain and use scalar bit tests for the branches.

X86 at least is able to use movmsk or kmov to move the mask to the scalar
domain. Then we can just use test instructions to test individual bits.

This is more efficient than extracting each mask element
individually.

I special cased v1i1 to use the previous behavior. This avoids
poor type legalization of bitcast of v1i1 to i1.

I've skipped expandload/compressstore as I think we need to
handle constant masks for those better first.

Many tests end up with duplicate test instructions due to tail
duplication in the branch folding pass. But the same thing
happens when constructing similar code in C. So its not unique
to the scalarization.

Not sure if this lowering code will also be good for other targets,
but we're only testing X86 today.

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

llvm-svn: 367489

[X86] Add DAG combine to fold any_extend_vector_inreg+truncstore to an extractelement+store

We have custom code that ignores the normal promoting type legalization on less than 128-bit vector types like v4i8 to emit pavgb, paddusb, psubusb since we don't have the equivalent instruction on a larger element type like v4i32. If this operation appears before a store, we can be left with an any_extend_vector_inreg followed by a truncstore after type legalization. When truncstore isn't legal, this will normally be decomposed into shuffles and a non-truncating store. This will then combine away the any_extend_vector_inreg and shuffle leaving just the store. On avx512, truncstore is legal so we don't decompose it and we had no combines to fix it.

This patch adds a new DAG combine to detect this case and emit either an extract_store for 64-bit stoers or a extractelement+store for 32 and 16 bit stores. This makes the avx512 codegen match the avx2 codegen for these situations. I'm restricting to only when -x86-experimental-vector-widening-legalization is false. When we're widening we're not likely to create this any_extend_inreg+truncstore combination. This means we should be able to remove this code when we flip the default. I would like to flip the default soon, but I need to investigate some performance regressions its causing in our branch that I wasn't seeing on trunk.

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

llvm-svn: 367488

Attempt to unbreak sphinx build bot by inserting a link.

llvm-svn: 367487

Migrate some more fadd and fsub cases away from UnsafeFPMath control to utilize NoSignedZerosFPMath options control

Summary: Honoring no signed zeroes is also available as a user control through clang separately regardless of fastmath or UnsafeFPMath context, DAG guards should reflect this context.

Reviewers: spatel, arsenm, hfinkel, wristow, craig.topper

Reviewed By: spatel

Subscribers: rampitec, foad, nhaehnle, wuzish, nemanjai, jvesely, wdng, javed.absar, MaskRay, jsji

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

llvm-svn: 367486

[IndVars, RLEV] Support rewriting exit values in loops without known exits (prep work)

This is a prepatory patch for future work on support exit value rewriting in loops with a mixture of computable and non-computable exit counts.  The intention is to be "mostly NFC" - i.e. not enable any interesting new transforms - but in practice, there are some small output changes.

The test differences are caused by cases wherewhere getSCEVAtScope can simplify a single entry phi without needing any knowledge of the loop.

llvm-svn: 367485

[NFC] allow creating error strings from a Twine

It's useful when no format needs to happen, only the Twine needs to be put together.

llvm-svn: 367484

Fix to r367374 "[MS] Emit S_HEAPALLOCSITE debug info in Selection DAG"
after windows buildbot failure.

Added a check that the MachineInstr exists and is a call before trying
to add symbols around it.

llvm-svn: 367483

Fix unused variable warning for non-assert builds.

llvm-svn: 367482

[GDBRemote] Reflow comments and improve docs.

Improved the GDB client base documentation while I was reading through
it. Looks like it got messed up during the automatic comment reflow a
while ago.

llvm-svn: 367481

[API] Remove use of ClangASTContext from SBTarget

Summary:
The methods to find types in a Target aren't clang specific and are
pretty generalizable to type systems. Additionally, to support some of
the use cases in SBTarget, I've added a "GetScratchTypeSystems" method
to Target to support getting all type systems for a target we are
debugging.

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

llvm-svn: 367480

[clang][ARM] Fix msvc arm{64} builtins to use int on LP64 systems.

The `InterlockedX_{acq,nf,rel}` functions deal with 32 bits which is long on
MSVC, but int on most other systems.

This also checks that `ReadStatusRegister` and `WriteStatusRegister` have
the correct type on aarch64-darwin.

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

llvm-svn: 367479

[NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

Second landing attempt: Changed TY_ObjCXXHeader to TY_PP_ObjCXXHeader to fix
                        -xobjective-c++-header. This time I verified against
                        preprocessor output.

Dropping the 'u' entry and the entire Flags table from Types.def.
Now it'll be a bit easier to tablegenify this.

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

llvm-svn: 367478

[GISel] Address review feedback on passing MD_callees to lowerCall.

Preserve the nullptr default for KnownCallees that appears in
the base class.

llvm-svn: 367477

[GISel] Pass MD_callees metadata down in call lowering.

Summary:
This will make it possible to improve IPRA by taking into account
register usage in indirect calls.

NFC yet; this is just laying the groundwork to start building
up patches to take advantage of the information for improved register
allocation.

Reviewers: aditya_nandakumar, volkan, qcolombet, arsenm, rovka, aemerson, paquette

Subscribers: sdardis, wdng, javed.absar, hiraditya, jrtc27, atanasyan, llvm-commits

Tags: #llvm

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

llvm-svn: 367476

AArch64: Add a tagged-globals backend feature.

This feature instructs the backend to allow locally defined global variable
addresses to contain a pointer tag in bits 56-63 that will be ignored by
the hardware (i.e. TBI), but may be used by an instrumentation pass such
as HWASAN. It works by adding a MOVK instruction to the regular ADRP/ADD
sequence that sets bits 48-63 to the corresponding bits of the global, with
the linker bounds check disabled on the ADRP instruction to prevent the tag
from causing a link failure.

This implementation of the feature omits the MOVK when loading from or storing
to a global, which is sufficient for TBI. If the same approach is extended
to MTE, assuming that 0 is not configured as a catch-all tag, we will most
likely also need the MOVK in this case in order to avoid a tag mismatch.

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

llvm-svn: 367475

SelectionDAG, MI, AArch64: Widen target flags fields/arguments from unsigned char to unsigned.

This makes the field wider than MachineOperand::SubReg_TargetFlags so that
we don't end up silently truncating any higher bits. We should still catch
any bits truncated from the MachineOperand field as a consequence of the
assertion in MachineOperand::setTargetFlags().

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

llvm-svn: 367474

Attempt to heal bots after r367467

llvm-svn: 367473

[DAGCombine] Limit the number of times for the same store and root nodes
to bail out in store merging dependence check.

We run into a case where dependence check in store merging bail out many times
for the same store and root nodes in a huge basicblock. That increases compile
time by almost 100x. The patch add a map to track how many times the bailing
out happen for the same store and root, and if it is over a limit, stop
considering the store with the same root as a merging candidate.

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

llvm-svn: 367472

compiler-rt: Rename .cc file in lib/sanitizer_common/symbolizer to .cpp

llvm-svn: 367471

[Support] Added overflow checking add, sub and mul.

Added AddOverflow, SubOverflow and MulOverflow to compute truncated results and return a flag indicating whether overflow occured.

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

llvm-svn: 367470

Attempt to heal tsan bot after r367463

llvm-svn: 367469

[pstl] Fully qualify pstl names.

Previously the code used "using namespace __pstl;" at block
scope to introduce these names. This could cause conflicts with
names defined by the standard library. So we should fully qualify
them instead.

llvm-svn: 367468

compiler-rt: Rename .cc file in lib/sanitizer_common/tests to .cpp

See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran

  for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $(basename $f) . ; done

and manually updated references to renamed files found by that.

llvm-svn: 367467

[X86] Add test cases to show premature decomposition of vector multiplies into shift+add/sub for types that aren't legal and need to be split. NFC

llvm-svn: 367466

[X86] Add AVX512DQ command lines to vector-mul.ll to show that we use vpmullq instead of shift+add/sub for some cases. NFC

llvm-svn: 367465

gn build: Merge r367463

llvm-svn: 367464

compiler-rt: Rename .cc file in lib/sanitizer_common to .cpp

See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran

  for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done

and manually updated (many) references to renamed files found by that.

llvm-svn: 367463

Attempt to heal bots after r367456

llvm-svn: 367462

[SCCP] Update condition to avoid overflow.

Summary:
Update condition to remove addition that may cause an overflow.
Resolves PR42814.

Reviewers: sanjoy, RKSimon

Subscribers: jlebar, llvm-commits

Tags: #llvm

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

llvm-svn: 367461

compiler-rt: Rename .cc file in lib/profile to .cpp

See https://reviews.llvm.org/D58620 for discussion.

Note how the comment in the file already said ".cpp" :)

llvm-svn: 367460

[CommandCompletions] Remove commented out code.

We use version control here.

llvm-svn: 367459

[docs] Add references to unreferenced footnotes.

Thanks to Stefan Granitz for catching the issue.

llvm-svn: 367458

gn build: Merge r367456

llvm-svn: 367457

compiler-rt: Rename .cc files in lib/interception to .cpp.

See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran

  for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done

and manually updated references to renamed files found by that.

llvm-svn: 367456

Fix completion for functions in anonymous namespaces

I was going through some of the old bugs and came across PR21069 which I
was able to reproduce. The issue is that we match the regex `^foo`
against the `DW_AT_name` in the DWARF, which for our anonymous function
is indeed `foo`. However, when we get the function name from the symbol
context, the result is `(anonymous namespace)::foo()`. This throws off
completions, which assumes that it's appending to whatever is already
present on the input, resulting in a bogus
`b fooonymous\ namespace)::foo()`.

Bug report: https://llvm.org/PR21069

Differential revision: https://reviews.llvm.org/D65498

llvm-svn: 367455

gn build: Merge r367452 and add standalone sources

llvm-svn: 367454

[clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

Summary:
Whitespace and comments are a clear bugfix: selecting some
comments/space near a statement doesn't mean you're selecting the
surrounding block.

Semicolons are less obvious, but for similar reasons: these tokens
aren't actually claimed by any AST node (usually), so an AST-based model
like SelectionTree shouldn't take them into account.

Callers may still sometimes care about semis of course:
 - when the selection is an expr with a non-expr parent, selection of
   the semicolon indicates intent to select the statement.
 - when a statement with a trailing semi is selected, we need to know
   its range to ensure it can be removed.
SelectionTree may or may not play a role here, but these are separate questions
from its core function of describing which AST nodes were selected.

The mechanism here is the TokenBuffer from syntax-trees. We use it in a
fairly low-level way (just to get boundaries of raw spelled tokens). The
actual mapping of AST nodes to coordinates continues to use the (fairly
mature) SourceLocation based logic. TokenBuffer/Syntax trees
don't currently offer an alternative to getFileRange(), I think.

Reviewers: SureYeaah, kadircet

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

Tags: #clang

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

llvm-svn: 367453

compiler-rt: Rename .cc files in lib/ubsan to .cpp.

See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran

  for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done

and manually updated references to renamed files found by that.

llvm-svn: 367452

[MemorySSA] Add additional verification for phis.

Summary:
Verify that the incoming defs into phis are the last defs from the
respective incoming blocks.
When moving blocks, insertDef must RenameUses. Adding this verification
makes GVNHoist tests fail that uncovered this issue.

Reviewers: george.burgess.iv

Subscribers: jlebar, Prazek, llvm-commits

Tags: #llvm

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

llvm-svn: 367451

gn build: Add build files for compiler-rt/lib/profile

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

llvm-svn: 367450

gn build: Make builtin library build on macOS

For now, it only builds the x86_64 slice.

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

llvm-svn: 367449

gn build: Fix redundant object files in builtin lib.

compiler-rt's builtin library has generic implementations of many
functions, and then per-arch optimized implementations of some.

In the CMake build, both filter_builtin_sources() and an explicit loop
at the end of the build file (see D37166) filter out the generic
versions if a per-arch file is present.

The GN build wasn't doing this filtering. Just do the filtering manually
and explicitly, instead of being clever.

While here, also remove files from the mingw/arm build that are
redundantly listed after D39938 / r318139 (both from the CMake and the
GN build).

While here, also fix a target_os -> target_cpu typo.

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

llvm-svn: 367448

[InstCombine] canonicalize fneg before fmul/fdiv

Reverse the canonicalization of fneg relative to fmul/fdiv. That makes it
easier to implement the transforms (and possibly other fneg transforms) in
1 place because we can always start the pattern match from fneg (either the
legacy binop or the new unop).

There's a secondary practical benefit seen in PR21914 and PR42681:
https://bugs.llvm.org/show_bug.cgi?id=21914
https://bugs.llvm.org/show_bug.cgi?id=42681
...hoisting fneg rather than sinking seems to play nicer with LICM in IR
(although this change may expose analysis holes in the other direction).

1. The instcombine test changes show the expected neutral IR diffs from
   reversing the order.

2. The reassociation tests show that we were missing an optimization
   opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says
   that all of these transforms are allowed (regardless of binop/unop
   fneg version) because:

   "For all other operations [besides copy/abs/negate/copysign], this
   standard does not specify the sign bit of a NaN result."
   In all of these transforms, we always have some other binop
   (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a
   potential intermediate NaN operand.
   (If that interpretation is wrong, then we must already have a bug in
   the existing transforms?)

3. The clang tests shouldn't exist as-is, but that's effectively a
   revert of rL367149 (the test broke with an extension of the
   pre-existing fneg canonicalization in rL367146).

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

llvm-svn: 367447

Reland "[DwarfDebug] Dump call site debug info"

The build failure found after the rL365467 has been
resolved.

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

llvm-svn: 367446

[docs][FIX] Add missing word to documentation in terms of SCCs

In the approval of D65299, commited as rL367440, I mentioned that my
proposed wording was lacking the word "maximal". It is added now for
correctness.

llvm-svn: 367445

[build] Add the ability to create a symlink for lipo

Add user enabled option to create lipo with symlink to llvm-lipo
Used rL326381 for reference.

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

llvm-svn: 367444

[AMDGPU] Fix for vectorizer crash with pointers of different size

When vectorizer strips pointers it can eventually end up with
pointers of two different sizes, then SCEV will crash.

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

llvm-svn: 367443

[Sanitizer][ASAN][MSAN] Fix infinite recursion on FreeBSD

Summary:
MSAN was broken on FreeBSD by https://reviews.llvm.org/D55703: after this
change accesses to the key variable call __tls_get_addr, which is
intercepted. The interceptor then calls GetCurrentThread which calls
MsanTSDGet which again calls __tls_get_addr, etc...
Using the default implementation in the SANITIZER_FREEBSD case fixes MSAN
for me.

I then applied the same change to ASAN (introduced in https://reviews.llvm.org/D55596)
but that did not work yet. In the ASAN case, we get infinite recursion
again during initialization, this time because calling pthread_key_create() early on
results in infinite recursion. pthread_key_create() calls sysctlbyname()
which is intercepted but COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED returns
true, so the interceptor calls internal_sysctlbyname() which then ends up
calling the interceptor again. I fixed this issue by using dlsym() to get
the libc version of sysctlbyname() instead.

This fixes https://llvm.org/PR40761

Reviewers: vitalybuka, krytarowski, devnexen, dim, bsdjhb, #sanitizers, MaskRay

Reviewed By: MaskRay

Subscribers: MaskRay, emaste, kubamracek, jfb, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

llvm-svn: 367442

Don't crash when pass by value struct has no definition.

llvm-svn: 367441

[docs] Reword documentation in terms of SCCs not cycles

Given the example:
header:
  br i1 %c, label %next, label %header
next:
  br i1 %c2, label %exit, label %header

We end up with a loop containing both header and next.  Given that, the describing the loop in terms of cycles is confusing since we have multiple distinct cycles within a single Loop.  Standardize on the SCC to clarify.

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

llvm-svn: 367440

[NFC][InstCombine] Add xor-or-icmp tests with icmp having extra uses

Currently InstCombiner::foldXorOfICmps() bailouts if the
ICMP it wants to invert has extra uses. As it can be seen
in the tests in previous commit, this is super unfortunate,
this is the single pattern that is left non-canonicalized.

We could analyze if we can also invert all the uses if said ICMP
at the same time, thus not bailing out there.
I'm not seeing any nicer alternative.

llvm-svn: 367439

[NFC][InstCombine] Add baseline tests with non-canonical CLAMP pattern

As disscussed in https://reviews.llvm.org/D65148#1603922
these would all need to be canonicalized to traditional clamp pattern.

llvm-svn: 367438

[AARCH64] Switch relocations R_AARCH64_TLS_TPREL64 and R_AARCH64_DTPMOD64

The ELF for the Arm 64-bit Architecture document originally specified
R_AARCH64_TLS_DTPREL64 = 0x404
R_AARCH64_TLS_DTPMOD64 = 0x405

LLVM correctly followed the document. Unfortunately in binutils these
two codes were reversed:
R_AARCH64_TLS_DTPMOD64 = 0x404
R_AARCH64_TLS_DTPREL64 = 0x405
Given that binaries had shipped this change has become the defacto standard
interpretation of these relocation codes for any toolchain that wanted to
remain compatible with GNU.

To recognize this the latest version of the ABI document has renamed
the relocations to R_AARCH64_TLS_IMPDEF1 and R_AARCH64_TLS_IMPDEF2
permitting a toolchain to choose between the two relocation types, and
recommending that toolchains follow the GNU interpretation for maximum
compatibility.

Given that upstream llvm has never implemented the standard TLS model for
AArch64 so we have no binary legacy, synchronize with GCC so that we don't
create incompatible objects in the future. So far the only visible change
is in llvm-readobj as it can decode these relocations. Tthis change will
mean that llvm-readobj decodes the same way as GNU readelf.

fixes PR40507

llvm-svn: 367437

[X86] Moved IsNOT helper earlier. NFCI.

Makes it available for more combines to use without adding declarations.

llvm-svn: 367436

[X86][SSE] Add test cases for PR42825

llvm-svn: 367435

[ARM] Reject CSEL instructions with invalid operands

Summary:
According to the Armv8.1-M manual CSEL, CSINC, CSINV and CSNEG are
"constrained unpredictable" when SP is used as the source register Rn.

The assembler should diagnose this case.

Reviewers: momchil.velikov, dmgreen, ostannard, simon_tatham, t.p.northover

Reviewed By: ostannard

Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367433

AMDGPU: Add missing builtin declarations

llvm-svn: 367431

[IPSCCP] Move callsite check to the beginning of the loop.

We have some code marks instructions with struct operands as overdefined,
but if the instruction is a call to a function with tracked arguments,
this breaks the assumption that the lattice values of all call sites
are not overdefined and will be replaced by a constant.

This also re-adds the assertion from D65222, with additionally skipping
non-callsite uses. This patch should address the cases reported in which
the assertion fired.

Fixes PR42738.

Reviewers: efriedma, davide

Reviewed By: efriedma

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

llvm-svn: 367430

[X86][AVX] Ensure chained subvector insertions are the same size (PR42833)

Before combining insert_subvector(insert_subvector(vec, sub0, c0), sub1, c1) patterns, ensure that the subvectors are all the same type. On AVX512 targets especially we might have a mixture of 128/256 subvector insertions.

llvm-svn: 367429

[AArch64] Add support for Transactional Memory Extension (TME)

Re-commit r366322 after some fixes

TME is a future architecture technology, documented in

  https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools
  https://developer.arm.com/docs/ddi0601/a

More about the future architectures:

  https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture

This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and
TCANCEL and the target feature/arch extension "tme".

It also implements TME builtin functions, defined in ACLE Q2 2019
(https://developer.arm.com/docs/101028/latest)

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

Patch by Javed Absar and Momchil Velikov

llvm-svn: 367428

[LLVM] Fix Alignment death tests in Release Mode

llvm-svn: 367427

[X86] Regenerate lrshrink test checks to make D65354 diff easier

llvm-svn: 367426

[X86] Regenerate callee-saved test checks to make D65354 diff easier

llvm-svn: 367425

[X86] Regenerate alias-static-alloca test checks to make D65354 diff easier

I've manually added the stack offsets back as these are worth keeping - we really need a way for update_llc_test_checks.py not to mask out useful address math

llvm-svn: 367424

[DivRemPairs] Fixup DNDEBUG build - variable is only used in assertion

llvm-svn: 367423

gn build: Merge r367393

llvm-svn: 367422

[X86] Regenerate vp2intersect tests

Enable nounwind to remove unnecessary stack manipulation code

llvm-svn: 367421

[lldb][NFC] Check in completion crash test case

llvm-svn: 367420

[DivRemPairs] Recommit: Handling for expanded-form rem - recomposition (PR42673)

Summary:
While `-div-rem-pairs` pass can decompose rem in div+rem pair when div-rem pair
is unsupported by target, nothing performs the opposite fold.
We can't do that in InstCombine or DAGCombine since neither of those has access to TTI.
So it makes most sense to teach `-div-rem-pairs` about it.

If we matched rem in expanded form, we know we will be able to place div-rem pair
next to each other so we won't regress the situation.
Also, we shouldn't decompose rem if we matched already-decomposed form.
This is surprisingly straight-forward otherwise.

The original patch was committed in rL367288 but was reverted in rL367289
because it exposed pre-existing RAUW issues in internal data structures
of the pass; those now have been addressed in a previous patch.

https://bugs.llvm.org/show_bug.cgi?id=42673

Reviewers: spatel, RKSimon, efriedma, ZaMaZaN4iK, bogner

Reviewed By: bogner

Subscribers: bogner, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367419

Fix issues with inferior stdout coming out of order

Summary:
We've had a bug where two pieces of code, executing on two threads were
attempting to write inferior output simultaneously. The first one was in
Debugger::HandleProcessEvent, which handled the cases where stdout was
coming while the process was running. The second was in
CommandInterpreter::IOHandlerInputComplete, which was ensuring that any
output is printed before the command which caused process to run
terminates.

Both of these things make sense, but the fact they were implemented as
two independent functions without any synchronization meant that race
conditions could occur (e.g. both threads call process->GetSTDOUT, get
two chunks of data, but then end up calling stream->Write in opposite
order). This was most apparent in situations where a process quickly
writes a bunch of output and then exits (as all our register tests do).

This patch adds a mutex to ensure that stdout forwarding happens
atomically. It also refactors a code somewhat in order to reduce code
duplication.

Reviewers: clayborg, jingham

Subscribers: jfb, mgorny, lldb-commits

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

llvm-svn: 367418

[DivRemPairs] Avoid RAUW pitfalls (PR42823)

Summary:
`DivRemPairs` internally creates two maps:
* {sign, divident, divisor} -> div instruction
* {sign, divident, divisor} -> rem instruction
Then it iterates over rem map, and looks if there is an entry
in div map with the same key. Then depending on some internal logic
it may RAUW rem instruction with something else.

But if that rem instruction is an input to other div/rem,
then it was used as a key in these maps, so the old value (used in key)
is now dandling, because RAUW didn't update those maps.
And we can't even RAUW map keys in general, there's `ValueMap`,
but we don't have a single `Value` as key...

The bug was discovered via D65298, and the test there exists.
Now, i'm not sure how to expose this issue in trunk.
The bug is clearly there if i change the map keys to be `AssertingVH`/`PoisoningVH`,
but i guess this didn't miscompiled anything thus far?
I really don't think this is benin without that patch.

The fix is actually rather straight-forward - instead of trying to somehow
shoe-horn `ValueMap` here (doesn't fit, key isn't just `Value`), or writing a new
`ValueMap` with key being a struct of `Value`s, we can just have an intermediate
data structure - a vector, each entry containing matching `Div, Rem` pair,
and pre-filling it before doing any modifications.
This way we won't need to query map after doing RAUW, so no bug is possible.

Reviewers: spatel, bogner, RKSimon, craig.topper

Reviewed By: spatel

Subscribers: hiraditya, hans, llvm-commits

Tags: #llvm

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

llvm-svn: 367417

[lldb][NFC] Check in another crashing test case

llvm-svn: 367416