[ARM] Fix infinite loop when lowering STRICT_FP_EXTEND

If the target has FP64 but not FP16 then we have custom lowering for FP_EXTEND
and STRICT_FP_EXTEND with type f64. However if the extend is from f32 to f64 the
current implementation will cause in infinite loop for STRICT_FP_EXTEND due to
emitting a merge_values of the original node which after replacement becomes a
merge_values of itself.

Fix this by not doing anything for f32 to f64 extend when we have FP64, though
for STRICT_FP_EXTEND we have to do the strict-to-nonstrict mutation as that
doesn't happen automatically for opcodes with custom lowering.

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

[OPENMP50]Fix handling of clauses in parallel master taskloop directive.

We need to capture correctly the value of num_tasks clause and should
not try to emit the if clause at all in the task region.

[MLIR][GPU] Implement initial mapping from loop.parallel to gpu.launch.

Summary:
To unblock other work, this implements basic lowering based on mapping
attributes that have to be provided on all loop.parallel. The lowering
does not yet support reduce.

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

[VectorCombine] adjust tests for extract-binop; NFC

We want the extra-use tests to be consistent with the
earlier single-use tests and be as cheap as possible
in vector form to show cost model edge cases. So use
i8 and extract from element 0 since that should be
cheap for all x86 targets.

[OPENMP]Fix the test, NFC.

[VectorCombine] add more extract-binop tests; NFC

See D74495.

[llvm][lldb] Update links to ABI for the Arm Architecture. [NFC]

[PowerPC][NFC] Small cleanup to restore CR field code in PPCFrameLowering.

Skip the loop over the CalleSavedInfos in 'restoreCalleeSavedRegisters' when
the register is a CR field and we are not targeting 32-bit ELF. This is safe
because:
1) The helper function 'restoreCRs' returns if the target is not 32-bit ELF,
   making all the code in the loop related to CR fields dead for every other
   subtarget. This code is only called on ELF right now, but the patch
   to extend it for AIX also needs to skip 'restoreCRs'.
2) The loop will not otherwise modify the iterator, so the iterator
   manipulations at the bottom of the loop end up setting 'I' to its
   current value.

This simplifciation allows us to remove one argument from 'restoreCRs'.

Also add a helper function to determine if a register is one of the
callee saved condition register fields.

attempt to fix check-clang on windows after c49866ac

[lldb] Introduce "RegInfoBasedABI"

Summary:
This patch creates a new subclass of the ABI class in order to abstract away the
mechanism in which we "augment" register information. This enables alternate
augmentation strategies to be introduced.

All existing ABI classes have been modified to inherit from RegInfoBasedABI, but
they will be refactored in subsequent patches.

Reviewers: JDevlieghere, jasonmolenda

Subscribers: sdardis, nemanjai, kbarton, jrtc27, atanasyan, jsji, lldb-commits

Tags: #lldb

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

Move FIXME to start of comment so visual studio actually tags it. NFC.

[X86][SSE] Add i686-SSE2 bswap vector tests

[gn build] Fix sync script on renames like "Foo.cpp" -> "LLVMFoo.cpp"

Before, the script used `git log -SFoo.cpp` to find a commit where
the number of occurrences of "Foo.cpp" changed -- but since
a patch with

  + LLVMFoo.cpp
  - Foo.cpp

contains the same number of instances of "Foo.cpp", the script
incorrectly skipped this type of rename.

As fix, look for '\bFoo\.cpp\b' instead and pass --pickaxe-regex
so that we can grep for word boundaries.

To test, check out 7531a5039fd (which renamed in llvm/lib/IR
RemarkStreamer.cpp to LLVMRemarkStreamer.cpp) and look at the output of
the script.  Before this change, it correctly assigned the addition
of LLVMRemarkStreamer.cpp to 7531a5039fd but incorrectly assigned
the removal of RemarkStreamer.cpp to b8a847c.  With this, it
correctly assigns both to 7531a5039fd.

[debuginfo-tests][Dexter] Fix some Windows-unfriendly Dexter behaviours

These are some minor things that I've run into on Windows, largely in
error handling paths:

 * Giving --lldb-executable on Windows triggers a "useless option" code
   path, which touches an attribute that only exists in the
   list_debuggers tool. Switch this to use hasattr, which will work in
   all subtools.
 * We were over-decoding some text reporting errors, but only in an
   exception path
 * The path to lldb on Windows needs to be quoted (even though dexter
   isn't making use of it).

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

[clangd] Expose Code Completion score to the client

Summary:
Make it possible for the client to adjust the ranking by using the score Clangd
calculates for the completion items.

Reviewers: sammccall

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

Tags: #clang

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

[lldb] Replace assertTrue(a == b, "msg") with assertEquals(a, b, "msg") in the test suite

Summary:
The error message from the construct `assertTrue(a == b, "msg") ` are nearly always completely useless for actually debugging the issue.
This patch is just replacing this construct (and similar ones like `assertTrue(a != b, ...)` with the proper call to assertEqual or assertNotEquals.

This patch was mostly written by a shell script with some manual verification afterwards:
```
lang=python
import sys

def sanitize_line(line):
  if line.strip().startswith("self.assertTrue(") and " == " in line:
    line = line.replace("self.assertTrue(", "self.assertEquals(")
    line = line.replace(" == ", ", ", 1)
  if line.strip().startswith("self.assertTrue(") and " != " in line:
    line = line.replace("self.assertTrue(", "self.assertNotEqual(")
    line = line.replace(" != ", ", ", 1)
  return line

for a in sys.argv[1:]:
  with open(a, "r") as f:
    lines = f.readlines()
  with open(a, "w") as f:
    for line in lines:
      f.write(sanitize_line(line))
```

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: abidh, lldb-commits

Tags: #lldb

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

Add '#include <functional>` to PassManager.h.

Summary:
On some platforms the build fails "std::function is not found". The include is used in
PassManager::IRPrinterConfig::enableIRPrinting.

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

[lldb] Fix lldb-dotest

to account for the new location of test files from 99451b445.

Fix integration of pass plugins with llvm dylib

Call llvm_process_pass_plugin from clang when in standalone mode.

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

Rework go bindings so that validation works fine

Basically change the layout to please `go build` and remove references to
`llvm-go`.

Update llvm/test/Bindings/Go/ to use the system go compiler

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

[PowerPC] Exploit VSX rounding instrs for rint

Exploit native VSX rounding instruction, x(v|s)r(d|s)pic, which does
rounding using current rounding mode.

According to C standard library, rint may raise INEXACT exception while
nearbyint won't.

Reviewed By: lkail

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

[analyzer] StdLibraryFunctionsChecker: Use platform dependent EOF and UCharMax

Summary:
Both EOF and the max value of unsigned char is platform dependent. In this
patch we try our best to deduce the value of EOF from the Preprocessor,
if we can't we fall back to -1.

Reviewers: Szelethus, NoQ

Subscribers: whisperity, xazax.hun, kristof.beyls, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalh

Tags: #clang

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

[debuginfo-tests] Fix Dexter process creation failure on Windows

When writing the Windows dbgeng driver for Dexter, I couldn't work out why it
would either launch a process and leave it free running, or if I started the
process suspended, never do anything with it. The result was a hack to create
and attach processes manually. This has been flaking out on Reids Windows
buildbot, and clearly wasn't a good solution.

Digging into this, it turns out that the "normal" cdb / windbg behaviour of
breaking whenever we attach to a process is not the default: it has to be
explicitly requested from the debug engine. This patch does so (by setting
DEBUG_ENGOPT_INITIAL_BREAK in the engine options), after which we can simply
call "CreateProcessAndAttach2" and everything automagically works.

No test for this behaviour: everything was just broken before.

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

[clangd] Print the Spelled RefKind.

Re-revert: Recover debug intrinsics when killing duplicated/empty blocks

This reverts commit 61b35e4111160fe834a00c33d040e01150b576ac.

This commit causes a timeout in chromium builds; likely to have a
similar cause to the previous timeout issue caused by this commit (see
6ded69f294a9 for more details). It is possible that there is no way to
fix this bug that will not cause this issue; further investigations as
to the efficiency of handling large amounts of debug info will be
necessary.

Fix the mac buildbot failure.

[clang] stop baremetal driver to append .a to lib

When the clang baremetal driver selects the rt.builtins static library
it prefix with "-l" and appends ".a". The result is a nonsense option
which lld refuses to accept.

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

Change-Id: Ic753b6104e259fbbdc059b68fccd9b933092d828

[AArch64] Fix BTI landing pad generation.

In some cases BTI landing pad is inserted even compatible instruction
was there already. Meta instruction does not count in this case
therefore skip them in the check for first instructions in the function.

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

[AArch64][SVE] Add mul/mla/mls lane & dup intrinsics

Summary:
Implements the following intrinsics:
 - @llvm.aarch64.sve.dup
 - @llvm.aarch64.sve.mul.lane
 - @llvm.aarch64.sve.mla.lane
 - @llvm.aarch64.sve.mls.lane

Reviewers: c-rhodes, sdesmalen, dancgr, efriedma, rengolin

Reviewed By: sdesmalen

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, cfe-commits, llvm-commits

Tags: #llvm

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

Fix unneeded semi column

[ARM] Fix ReconstructShuffle for bigendian

Simon pointed out that this function is doing a bitcast, which can be
incorrect for big endian. That makes the lowering of VMOVN in MVE
wrong, but the function is shared between Neon and MVE so both can
be incorrect.

This attempts to fix things by using the newly added VECTOR_REG_CAST
instead of the BITCAST. As it may now be used on Neon, I've added the
relevant patterns for it there too. I've also added a quick dag combine
for it to remove them where possible.

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

[ARM] Extra vmovn tests to show BE differences. NFC

[NFC][llvm-exegesis] Docs/help: opcode-index=-1 means measure everything

[LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols.

Recommit of 0b4a047bfbd11fe1f5abda8da0e2391c1918162a
(reverted in c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) to incorporate
subsequent fix and add a warning when LLD's interworking behavior has
changed.

D73474 disabled the generation of interworking thunks for branch
relocations to non STT_FUNC symbols. This patch handles the case of BL and
BLX instructions to non STT_FUNC symbols. LLD would normally look at the
state of the caller and the callee and write a BL if the states are the
same and a BLX if the states are different.

This patch disables BL/BLX substitution when the destination symbol does
not have type STT_FUNC. This brings our behavior in line with GNU ld which
may prevent difficult to diagnose runtime errors when switching to lld.

This change does change how LLD handles interworking of symbols that do not
have type STT_FUNC from previous versions including the 10.0 release. This
brings LLD in line with ld.bfd but there may be programs that have not been
linked with ld.bfd that depend on LLD's previous behavior. We emit a warning
when the behavior changes.

A summary of the difference between 10.0 and 11.0 is that for symbols
that do not have a type of STT_FUNC LLD will not change a BL to a BLX or
vice versa. The table below enumerates the changes
| relocation     | STT_FUNC | bit(0) | in  | 10.0- out | 11.0+ out |
| R_ARM_CALL     | no       | 1      | BL  | BLX       | BL        |
| R_ARM_CALL     | no       | 0      | BLX | BL        | BLX       |
| R_ARM_THM_CALL | no       | 1      | BLX | BL        | BLX       |
| R_ARM_THM_CALL | no       | 0      | BL  | BLX       | BL        |

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

[lldb] Clean up ProcessGDBRemote::DidLaunchOrAttach

- reduce indentation by removing the defensive
  GetID()!=INVALID_PROCESS_ID check -- this function is only called when
  an attach or launch succeeds
- replace LLDB_LOGF with LLDB_LOG

[clangd] Query constructors in the index during rename.

Summary:
Though this is not needed when using clangd's own index, other indexes
(e.g. kythe) need it, as classes and their constructors are different
symbols, otherwise we will miss renaming constructors.

Reviewers: kbobyrev

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

Tags: #clang

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

Don't call memcpy(p, 0, 0).

Found by UBSan, reported by Kostya. Thanks!

[DebugInfo] Fix dumping CIE ID in .eh_frame sections.

We do not keep the actual value of the CIE ID field, because it is
predefined, and use a constant when dumping a CIE record. The issue
was that the predefined value is different for .debug_frame and
.eh_frame sections, but we always printed the one which corresponds
to .debug_frame. The patch fixes that by choosing an appropriate
constant to print.

See the following for more information about .eh_frame sections:
https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html

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

[mlir] Add elementAttr to TypedArrayAttrBase.

In code generators, one can automate the translation of typed ArrayAttrs
if element attribute translators are already implemented. However, the
type of the element attribute is lost at the construction of
TypedArrayAttrBase. With this change one can inspect the element type
and generate the translation logic automatically, which will reduce the
code repetition.

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

[NFC][mlir] Adding some helpful EDSC intrinsics

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

[lldb] Make gdbremote.py utility py2and3 compatible

[mlir][DeclarativeParser] Move operand type resolution into a functor to
share code.

This reduces the duplication for the two different cases.

[mlir][ODS][NFC] Mark OpaqueType as a buildable type.

This allows for using it in the declarative assembly form, among other
things.

[OpenMP][FIX] Collect blocks to be outlined after finalization

Finalization can introduce new blocks we need to outline as well so it
makes sense to identify the blocks that need to be outlined after
finalization happened. There was also a minor unit test adjustment to
account for the fact that we have a single outlined exit block now.

[ELF][test] Change -o %t to -o /dev/null if the output is not needed

Explicitly state the output file.

Summary:
Even though this test is a check for failure, lld still attempts
to open the final output file, which fails when the default "a.out"
file is used and the current directory is read-only. Specifying an
output file works around this problem.

Reviewers: espindola

Subscribers: emaste, MaskRay, llvm-commits

Tags: #llvm

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

Revert "Replace std::foo with std::foo_t in LLVM."

This reverts commit a4384c756bd8a819051009b5b273b2a34be8261b.

These changes break LLVM build on Windows builders.

See https://reviews.llvm.org/rGa4384c756bd8a819051009b5b273b2a34be8261b
for details.

[X86] Add test RUN lines to show cases where we use 512-bit vcmppd/ps with garbage upper bits for 128/256-bit strict_fsetcc

On KNL targets, we widen 128/256-bit strict_fsetcc nodes to
512-bits without forcing the upper bits to zero. This can cause
spurious exceptions due to garbage upper bits. This behavior was
inherited from the non-strict case where the spurious exception
isn't a problem.

[BPF] explicit warning of not supporting dynamic stack allocation

Currently, BPF does not support dynamic static allocation.
For a program like below:
  extern void bar(int *);
  void foo(int n) {
    int a[n];
    bar(a);
  }

The current error message looks like:
  unimplemented operand
  UNREACHABLE executed at /.../llvm/lib/Target/BPF/BPFISelLowering.cpp:199!

Let us make error message explicit so it will be clear to the user
what is the problem. With this patch, the error message looks like:
  fatal error: error in backend: Unsupported dynamic stack allocation
  ...

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

Reapply "[OpenMP][IRBuilder] Perform finalization (incl. outlining) late"

Reapply 8a56d64d7620b3764f10f03f3a1e307fcdd72c2f with minor fixes.

The problem was that cancellation can cause new edges to the parallel
region exit block which is not outlined. The CodeExtractor will encode
the information which "exit" was taken as a return value. The fix is to
ensure we do not return any value from the outlined function, to prevent
control to value conversion we ensure a single exit block for the
outlined region.

This reverts commit 3aac953afa34885a72df96f2b703b65f85cbb149.

[Statepoint] Remove redundant clear of call target on register

Patchable statepoint is lowered into sequence of nops, so zeroed call target
should not be on register. It is better to use getTargetConstant instead
of getConstant to select zero constant for call target.

Reviewers: reames
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D74465

[AMDGPU][GlobalISel] Handle 64byte EltSIze in getRegSplitParts

Reviewers: arsenm

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

Tags: #llvm

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

Fix regression due to reviews.llvm.org/D74436 by adding option ffp-contract=off to RUN line

Fix ReST syntax on link to "Bisecting LLVM code" page

Patch from nicolas17 (Nicolás Alvarez)!

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

[MLIR][Affine] Add affine.parallel op

Summary:
As discussed in https://llvm.discourse.group/t/rfc-add-affine-parallel/350, this is the first in a series of patches to bring in support for the `affine.parallel` operation.

This first patch adds the IR representation along with custom printer/parser implementations.

Reviewers: bondhugula, herhut, mehdi_amini, nicolasvasilache, rriddle, earhart, jbruestle

Reviewed By: bondhugula, nicolasvasilache, rriddle, earhart, jbruestle

Subscribers: jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, llvm-commits

Tags: #llvm

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

[AsmPrinter][ELF] Emit local alias for ExternalLinkage dso_local GlobalAlias

Revert "[X86][SSE] lowerShuffleAsBitRotate - lower to vXi8 shuffles to ROTL on pre-SSSE3 targets"

This reverts commit 11c16e71598d51f15b4cfd0f719c4dabcc0bebf7 because it
causes a crash in chromium code. See
https://reviews.llvm.org/rG11c16e71598d51f15b4cfd0f719c4dabcc0bebf7.

Revert "[OpenMP][IRBuilder] Perform finalization (incl. outlining) late"

This reverts commit 8a56d64d7620b3764f10f03f3a1e307fcdd72c2f.

Will be recommitted once the clang test problem is addressed.

AMDGPU/GlobalISel: Select G_CTTZ_ZERO_UNDEF

Directly select this rather than going through the intermediate
instruction, which may provide some combine value in the future.

AMDGPU/GlobalISel: Select G_CTLZ_ZERO_UNDEF

Directly select this rather than going through the intermediate
instruction, which may provide some combine value in the future.

AMDGPU/GlobalISel: Fix mapping G_ICMP with constrained result

When SI_IF is inserted, it constrains the source register with a
register class, which was quite likely a G_ICMP. This was incorrectly
treating it as a scalar, and then applyMappingImpl would end up
producing invalid MIR since this was unexpected.

Also fix not using all VGPR sources for vcc outputs.

PPC: Prepare tests for switch of default denormal-fp-math

These tests fail when the default is switched to assume IEEE denormal
handling. I'm not sure if PPC really has a way to control the denormal
input handling.

Replace std::foo with std::foo_t in LLVM.

This patch is replacements missed in my last change doing this across LLVM.

No functional change, although I think there was a missing typename
in struct conjunction that is now fixed.

[GWP-ASan] [NFC] Change enum from ANDROID->BIONIC.

[Fuzzer] Rename ExecuteCommandWithPopen to ExecuteCommandNon-Fushsia target will keep using popen/pclose implementation. OnFuchsia, Two-args version of `ExecuteCommand` is a simple wrapper of theone-arg version. (Hopefully) Fix D73329 build on Fuchsia.

[OpenMP][IRBuilder] Perform finalization (incl. outlining) late

In order to fix PR44560 and to prepare for loop transformations we now
finalize a function late, which will also do the outlining late. The
logic is as before but the actual outlining step happens now after the
function was fully constructed. Once we have loop transformations we
can apply them in the finalize step before the outlining.

Reviewed By: JonChesterfield

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

Fix a reentrance bug with deserializing ObjC type parameters.

This is a longstanding bug that seems to have been hidden by
a combination of (1) the normal flow being to deserialize the
interface before deserializing its parameter and (2) a precise
ordering of work that was apparently recently disturbed,
perhaps by my abstract-serialization work or Bruno's ObjC
module merging work.

Fixes rdar://59153545.

[Attributor] Use fine-grained liveness in all helpers

We used coarse-grained liveness before, thus we looked if the
instruction was executed, but we did not use fine-grained liveness,
hence if the instruction was needed or could be deleted even if the
surrounding ones are live. This patches introduces this level of
liveness checks together with other liveness queries, e.g., for uses.

For more control we enforce that all liveness queries go through the
Attributor.

Test have been adjusted to reflect the changes or augmented to prevent
deletion of the parts we want to check.

Reviewed By: sstefan1

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

[Attributor] Ignore uses if a value is simplified

If we have a replacement for a value, via AAValueSimplify, the original
value will lose all its uses. Thus, as long as a value is simplified we
can skip the uses in checkForAllUses, given that these uses are
transitive uses for the simplified version and will therefore affect the
simplified version as necessary.

Since this allowed us to remove calls without side-effects and a known
return value, we need to make sure not to eliminate `musttail` calls.
Those we keep around, or later remove the entire `musttail` call chain.

[Attributor] Use assumed information to determine side-effects

We relied on wouldInstructionBeTriviallyDead before but that functions
does not take assumed information, especially for calls, into account.
The replacement, AAIsDead::isAssumeSideEffectFree, does.

This change makes AAIsDeadCallSiteReturn more complex as we can have
a dead call or only dead users.

The test have been modified to include a side effect where there was
none in order to keep the coverage.

Reviewed By: sstefan1

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

Changed omp_get_max_threads() implementation to more closely match spec description.

Summary: The 5.0 spec states, "The omp_get_max_threads routine returns an upper bound on the number of threads that could be used to form a new team if a parallel construct without a num_threads clause were encountered after execution returns from this routine." The attached test shows Max Threads: 96, Num Threads: 128 without the proposed change. The number of threads should not exceed the (max) nthreads ICV, hence we should return the higher SPMD thread number even when omp_get_max_threads() is called in a generic kernel. This change does fail the api test, max_threads.c, because now it would return 64 instead of 32.

Reviewers: jdoerfert, ABataev, grokos, JonChesterfield

Reviewed By: jdoerfert

Subscribers: openmp-commits

Tags: #openmp

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

[libomptarget][nfc] Change enum values to match those in cuda/rtl

Summary:
[libomptarget][nfc] Change enum values to match those in cuda/rtl

support.h and cuda/rtl.cpp (and downsteam hsa/rtl.cpp) have enums for execution
mode. These are actually independent - the numbers that used within support, or
within the plugin, are never passed across the boundary.

Nevertheless, trying to work out why the values are different between the two
has generated a reasonable amount of confusion. This patch changes support to
match the values in plugin, on the basis that the plugin also has some comments
which I'd have to update if I changed that one instead. Credit to Ron for
working through this in our own fork. See rocm-developer-tools/aomp/issues/7
for that earlier diagnostic write up.

Also happy with generic = 0, spmd = 1 - provided it's the same in both places.

Reviewers: jdoerfert, grokos, ABataev, ronlieb

Reviewed By: grokos

Subscribers: openmp-commits

Tags: #openmp

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

[GWP-ASan] Update alignment on Android.

Summary:
Android has different alignment requirements. You can read more about
them here
(https://cs.android.com/android/platform/superproject/+/master:bionic/tests/malloc_test.cpp;l=808),
but the general gist is that for malloc(x <= 8), we do malloc(8), and
for everything else, we do 16-byte alignment.

Reviewers: eugenis, morehouse, cferris

Reviewed By: eugenis, morehouse

Subscribers: #sanitizers, llvm-commits, pcc

Tags: #sanitizers, #llvm

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

[MBP] Partial tail duplication into hot predecessors

Current tail duplication embedded in MBP duplicates a BB into all or none of its predecessors without too much cost analysis. So sometimes it is duplicated into cold predecessors, and in other cases it may miss the duplication into hot predecessors.

This patch improves tail duplication in 3 aspects:

  A successor can be duplicated into part of its predecessors.
  A more fine-grained benefit analysis, combined with 1, now a successor is duplicated into hot predecessors only.
  If a successor can't be duplicated into one predecessor, it doesn't impact the duplication into other predecessors.

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

[CMake][Fuchsia] Enable in-process cc1

This is now supported by Goma so we can re-enable it.

[Clang] Limit -fintegrated-cc1 to only one TU

As discussed in https://reviews.llvm.org/D74447, this patch disables integrated-cc1 behavior if there's more than one job to be executed. This is meant to limit memory bloating, given that currently jobs don't clean up after execution (-disable-free is always active in cc1 mode).

I see this behavior as temporary until release 10.0 ships (to ease merging of this patch), then we'll reevaluate the situation, see if D74447 makes more sense on the long term.

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

[Clang] When -ftime-trace is used, clean CompilerInstance::OutputFiles before exiting cc_main()

This fixes cc1 execution when '-disable-free' is not used (currently not the case, that flag is always used for cc1).

[mlir][Linalg] Fix build warnings

[lldb/Plugins] Move DynamicLoaderMacOS into DynamicLoaderMacOSXDYLD (NFCI)

Move the logic for initialization and termination for DynamicLoaderMacOS
into DynamicLoaderMacOSXDYLD so that there's one initializer for the
DynamicLoaderMacOSXDYLD plugin.

[mlir] support creating memref descriptors from static shape with non-zero offset

This patch adapts the method MemRefDescriptor::fromStaticShape to
support static non-zero offsets. The updated method uses the
getStridesAndOffset method to extract strides and offset. The patch also
adapts the test cases since sizes and strides are now set in forward
instead of reverse order.

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

[MLIR] Fix wrong header for mlir-cuda-runner

Just updated the wrong header probably copied from the mlir-cpu-runner

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

Fix type-dependency of bitfields in templates

This patch is a follow up to 878a24ee244a24. Name of bitfields
with value-dependent width should be set as type-dependent. This
patch adds the required value-dependency check and sets the
type-dependency accordingly.

Patch fixes PR44886

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

[TBLGEN] Fix subreg value overflow in DAGISelMatcher

Tablegen's DAGISelMatcher emits integers in a VBR format,
so if an integer is below 128 it can fit into a single
byte, otherwise high bit is set, next byte is used etc.
MatcherTable is essentially an unsigned char table. When
SelectionDAGISel parses the table it does a reverse translation.

In a situation when numeric value of an integer to emit is
unknown it can be emitted not as OPC_EmitInteger but as
OPC_EmitStringInteger using a symbolic name of the value.
In this situation the value should not exceed 127.

One of the situations when OPC_EmitStringInteger is used is
if we need to emit a subreg into a matcher table. However,
number of subregs can exceed 127. Currently last defined subreg
for AMDGPU is 192. That results in a silent bug in the ISel
with matcher reading from an invalid offset.

Fixed this bug to emit actual VBR encoded value for a subregs
which value exceeds 127.

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

[docs] Minor updates to DeveloperPolicy due to svn to git

Reviewed By: efriedma

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

[README] Add note on using cmake to perform the build

Also, some spelling fixes.  Test commit.

[OpenMP] update strings output of libomp.so [NFC]

Change the string from "Intel(R) OMP" to "LLVM OMP" in libomp.so

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

[LoopExtractor] Fix legacy pass dependencies

Fixes a memory leak of allocating `LoopInfoWrapperPass` and `DominatorTreeWrapperPass`.

[llvm-exegesis] CombinationGenerator: don't store function_ref

function_ref is non-owning, so if we get it as a parameter in constructor,
our reference goes out-of-scope as soon as constructor returns.
Instead, let's just take it as a parameter to the actual `generate()` call

Revert "[IRGen] Emit lifetime intrinsics around temporary aggregate argument allocas"

This reverts commit fafc6e4fdf3673dcf557d6c8ae0c0a4bb3184402.

Should fix ppc stage2 failure: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/23546

Conflicts:
clang/lib/CodeGen/CGCall.cpp

[mlir][Linalg] Refactor in preparation for automatic Linalg "named" ops.

This revision prepares the ground for declaratively defining Linalg "named" ops.
Such named ops form the backbone of operations that are ubiquitous in the ML
application domain.

This revision closely related to the definition of a "Tensor Computation
Primitives Dialect" and demonstrates that ops can be expressed as declarative
configurations of the `linalg.generic` op.

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

[lldb/Plugins] Move SymbolFileDWARFDebugMap into SymbolFileDWARF (NFCI)

Move the logic for initialization and termination for
SymbolFileDWARFDebugMap into SymbolFileDWARF so that there's one
initializer for the SymbolFileDWARF plugin.

[lldb/LibCxx] Have ExtractLibcxxStringInfo return an Optional result, NFC

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

[lldb/StringPrinter] Avoid reading garbage in uninitialized strings

This patch fixes a few related out-of-bounds read bugs in the
string data formatters. These issues have to do with mishandling of un-
initialized strings. These manifest as ASan exceptions when debugging a
clang binary.

The first issue was that the std::string formatter treated strings in
"short mode" with length greater than the size of the inline buffer as
valid.

The second issue was that the StringPrinter facility did not check that
a full utf8 codepoint sequence can be read from the buffer (i.e. there
are some missing range checks). I took the opportunity here to delete
some untested code that was meant to deal with invalid input and replace
it with fail-on-invalid logic ([1][2][3]). This means we'll give up on
formatting an invalid string instead of guessing our way through it.

The third issue is that StringPrinter did not check that a utf8 sequence
could actually be fully read from the string payload. This one is especially
tricky as we may overflow the buffer pointer while reading the sequence.

I also noticed that the std::string formatter would spew the raw version of
the underlying ValueObject when garbage is detected. I've changed this to
just print "Summary Unavailable" instead, as we do elsewhere.

I've added regression tests for these issues to
test/functionalities/data-formatter/data-formatter-stl/libcxx/string.

[1]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L136
[2]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L163
[3]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L357

rdar://59080026

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

[lldb/TypeSystemClang] Supply trivial TypeSourceInfo to NonTypeTemplateParmDecl::Create

This fixes a UBSan error seen while debugging clang:

Member call on null pointer of type 'clang::TypeSourceInfo'

rdar://58783517

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

[AddressSanitizer] Ensure only AllocaInst is passed to dbg.declare

Various parts of the LLVM code generator assume that the address
argument of a dbg.declare is not a `ptrtoint`-of-alloca. ASan breaks
this assumption, and this results in local variables sometimes being
unavailable at -O0.

GlobalISel, SelectionDAG, and FastISel all do not appear to expect
dbg.declares to have a `ptrtoint` as an operand. This means that they do
not place entry block allocas in the usual side table reserved for local
variables available in the whole function scope. This isn't always a
problem, as LLVM can try to lower the dbg.declare to a DBG_VALUE, but
those DBG_VALUEs can get dropped for all the usual reasons DBG_VALUEs
get dropped. In the ObjC test case I'm looking at, the cause happens to
be that `replaceDbgDeclare` has hoisted dbg.declares into the entry
block, causing LiveDebugValues to "kill" the DBG_VALUEs because the
lexical dominance check fails.

To address this, I propose:

1) Have ASan (always) pass an alloca to dbg.declares (this patch). This
   is a narrow bugfix for -O0 debugging.

2) Make replaceDbgDeclare not move dbg.declares around. This should be a
   generic improvement for optimized debug info, as it would prevent the
   lexical dominance check in LiveDebugValues from killing as many
   variables.

   This means reverting llvm/r227544, which fixed an assertion failure
   (llvm.org/PR22386) but no longer seems to be necessary. I was able to
   complete a stage2 build with the revert in place.

rdar://54688991

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

[KnownBits] Introduce anyext instead of passing a flag into zext

Summary:
This was a very odd API, where you had to pass a flag into a zext
function to say whether the extended bits really were zero or not. All
callers passed in a literal true or false.

I think it's much clearer to make the function name reflect the
operation being performed on the value we're tracking (rather than on
the KnownBits Zero and One fields), so zext means the value is being
zero extended and new function anyext means the value is being extended
with unknown bits.

NFC.

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

[mlir][EDSC][Linalg] Compose linalg_matmul and vector.contract

Summary:
This revision allows model builder to create a linalg_matmul whose body
is a vector.contract. This shows the abstractions compose nicely.

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

[gn build] Port 6030fe01f4e

[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE

Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)

Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.

Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.

Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.

As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.

Reviewers: courbet, gchatelet

Reviewed By: gchatelet

Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits

Tags: #llvm

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

Completely ignore strict FP model and denormal-fp-math interaction

No behavior is going to make sense here until the default is IEEE.