[NFC] Show instcombine powi simplifications drop FMF

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

[X86] In shrinkAndImmediate, place the new constant into the topological sort.

Revert the change to use APInt::isSignedIntN from
5ff5cf8e057782e3e648ecf5ccf1d9990b53ee90.

Its clear that the games we were playing to avoid the topological
sort aren't working. So just fix it once and for all.

Fixes PR48888.

[NFC][lit] Cleanup code using string interpolation

LLVM now requires Python 3.6, so we can use string interpolation to make
code more readable.

[GlobalISel][IRTranslator] Ignore the llvm.experimental.noalias.scope.decl intrinsic.

These don't generate any code.

[OpenMP][Libomptarget] Fix cmake error on remote plugin

Requiring 3.15 causes a build breakage, I'm sure none of the contents actually require
3.15 or above.

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

[gn build] Port 1e634f3952aa

[llvm-elfabi] Fix test after D95140

[libomptarget][cuda] Gracefully handle missing cuda library

[libomptarget][cuda] Gracefully handle missing cuda library

If using dynamic cuda, and it failed to load, it is not safe to call
cuGetErrorString.

Reviewed By: jdoerfert

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

[libomptarget][cuda] Only run tests when sure there is cuda available

[libomptarget][cuda] Only run tests when sure there is cuda available

Prior to D95155, building the cuda plugin implied cuda was installed locally.
With that change, every machine can build a cuda plugin, but they won't all have
cuda and/or an nvptx card installed locally.

This change enables the nvptx tests when either:
- libcuda is present
- the user has forced use of the dlopen stub

The default case when there is no cuda detected will no longer attempt to
run the tests on nvptx hardware, as was the case before D95155.

Reviewed By: jdoerfert, ronlieb

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

[OpenMP][Libomptarget] Introduce Remote Offloading Plugin

This introduces a remote offloading plugin for libomptarget. This
implementation relies on gRPC and protobuf, so this library will only
build if both libraries are available on the system. The corresponding
server is compiled to `openmp-offloading-server`.

This is a large change, but the only way to split this up is into RTL/server
but I fear that could introduce an inconsistency amongst them.

Ideally, tests for this should be added to the current ones that but that is
problematic for at least one reason. Given that libomptarget registers plugin
on a first-come-first-serve basis, if we wanted to offload onto a local x86
through a different process, then we'd have to either re-order the plugin list
in `rtl.cpp` (which is what I did locally for testing) or find a better
solution for runtime plugin registration in libomptarget.

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

[llvm-elfabi] Support ELF file that lacks .gnu.hash section

Before this change, when reading ELF file, elfabi determines number of
entries in .dynsym by reading the .gnu.hash section. This change makes
elfabi read section headers directly first. This change allows elfabi
works on ELF files which do not have .gnu.hash sections.

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

[libc++] Fix oss-fuzz build

Add -fbinutils-version= to gate ELF features on the specified binutils version

There are two use cases.

Assembler
We have accrued some code gated on MCAsmInfo::useIntegratedAssembler().  Some
features are supported by latest GNU as, but we have to use
MCAsmInfo::useIntegratedAs() because the newer versions have not been widely
adopted (e.g. SHF_LINK_ORDER 'o' and 'unique' linkage in 2.35, --compress-debug-sections= in 2.26).

Linker
We want to use features supported only by LLD or very new GNU ld, or don't want
to work around older GNU ld. We currently can't represent that "we don't care
about old GNU ld".  You can find such workarounds in a few other places, e.g.
Mips/MipsAsmprinter.cpp PowerPC/PPCTOCRegDeps.cpp X86/X86MCInstrLower.cpp
AArch64 TLS workaround for R_AARCH64_TLSLD_MOVW_DTPREL_* (PR ld/18276),
R_AARCH64_TLSLE_LDST8_TPREL_LO12 (https://bugs.llvm.org/show_bug.cgi?id=36727 https://sourceware.org/bugzilla/show_bug.cgi?id=22969)

Mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER components (supported by LLD in D84001;
GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=16833 may take a while before available).
This feature allows to garbage collect some unused sections (e.g. fragmented .gcc_except_table).

This patch adds `-fbinutils-version=` to clang and `-binutils-version` to llc.
It changes one codegen place in SHF_MERGE to demonstrate its usage.
`-fbinutils-version=2.35` means the produced object file does not care about GNU
ld<2.35 compatibility. When `-fno-integrated-as` is specified, the produced
assembly can be consumed by GNU as>=2.35, but older versions may not work.

`-fbinutils-version=none` means that we can use all ELF features, regardless of
GNU as/ld support.

Both clang and llc need `parseBinutilsVersion`. Such command line parsing is
usually implemented in `llvm/lib/CodeGen/CommandFlags.cpp` (LLVMCodeGen),
however, ClangCodeGen does not depend on LLVMCodeGen. So I add
`parseBinutilsVersion` to `llvm/lib/Target/TargetMachine.cpp` (LLVMTarget).

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

Revert "Support for instrumenting only selected files or functions"

This reverts commit 4edf35f11a9e20bd5df3cb47283715f0ff38b751 because
the test fails on Windows bots.

Make SBDebugger::CreateTargetWithFileAndArch work with lldb::LLDB_DEFAULT_ARCH

Second try, handling both a bogus arch string and the "null file & arch" used
to create an empty but valid target.
Also check in that case before logging (previously the logging would have
crashed.)

[flang][openacc][NFC] Organize clause validity tests by directive

Split the tests from acc-clause-validity.f90 in dedicated files by directives.
The file acc-clause-validity.f90 was getting too big to be correctly maintained.
Tests are identical.

Reviewed By: SouraVX

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

CGDebugInfo CreatedLimitedType: Drop file/line for RecordType with invalid location

For Clang synthesized `__va_list_tag` (`CreateX86_64ABIBuiltinVaListDecl`),
its DW_AT_decl_file/DW_AT_decl_line are arbitrarily set from `CurLoc`.

In a stage 2 `-DCMAKE_BUILD_TYPE=Debug` clang build, I observe that
in driver.cpp, DW_AT_decl_file/DW_AT_decl_line may be set to an `#include` line
(the transitively included file uses va_arg (`__builtin_va_arg`)).
This seems arbitrary. Drop that.

Reviewed By: #debug-info, dblaikie

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

CGDebugInfo: Drop Loc.isInvalid() special case from getLineNumber

`getLineNumber()` picks CurLoc if the parameter is invalid. This appears to
mainly work around missing SourceLocation information for some constructs, but
sometimes adds unintended locations.

* For `CodeGenObjC/debug-info-blocks.m`, `CurLoc` has been advanced to the closing brace. The debug line of `ImplicitVarParameter` is set to the line of `}` because this implicit parameter has an invalid `SourceLocation`. The debug line is a bit arbitrary - perhaps the location of `^{` is better.
* The file/line of Clang synthesized `__va_list_tag` is arbitrarily attached a `#include` line. D94735

Drop the special case to make getLineNumber less magic and add CurLoc fallback in its callers instead.

Tested with stage 2 -DCMAKE_BUILD_TYPE=Debug clang, byte identical.

Reviewed By: #debug-info, aprantl

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

[AMDGPU] Update subtarget features for new target ID support

Support for XNACK and SRAMECC is not static on some GPUs. We must be able
to differentiate between different scenarios for these dynamic subtarget
features.

The possible settings are:

- Unsupported: The GPU has no support for XNACK/SRAMECC.
- Any: Preference is unspecified. Use conservative settings that can run anywhere.
- Off: Request support for XNACK/SRAMECC Off
- On: Request support for XNACK/SRAMECC On

GCNSubtarget will track the four options based on the following criteria. If
the subtarget does not support XNACK/SRAMECC we say the setting is
"Unsupported". If no subtarget features for XNACK/SRAMECC are requested we
must support "Any" mode. If the subtarget features XNACK/SRAMECC exist in the
feature string when initializing the subtarget, the settings are "On/Off".

The defaults are updated to be conservatively correct, meaning if no setting
for XNACK or SRAMECC is explicitly requested, defaults will be used which
generate code that can be run anywhere. This corresponds to the "Any" setting.

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

[OpenMP][Libomptarget] Introduce changes to support remote plugin

In order to support remote execution, we need to be able to send the
target binary description to the remote host for registration (and
consequent deregistration). To support this, I added these two
optional new functions to the plugin API:
- `__tgt_rtl_register_lib`
- `__tgt_rtl_unregister_lib`

These functions will be called to properly manage the instance of
libomptarget running on the remote host.

Reviewed By: JonChesterfield

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

[gn build] Port 4edf35f11a9e

Support for instrumenting only selected files or functions

This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
sanitizer special case list format to select which files and functions
to instrument, and relies on the new noprofile IR attribute to exclude
functions from instrumentation.

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

[libomptarget][devicertl][amdgpu] Fix build, variable renaming error

[clangd] FindTarget resolves base specifier

FindTarget on the virtual keyword or access specifier of a base specifier will now resolve to type of the base specifier.

Reviewed By: sammccall

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

[clangd] Selection handles CXXBaseSpecifier

Selection now includes the virtual and access modifier as part of their range for cxx base specifiers.

Reviewed By: sammccall

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

[ARM] [ELF] Fix ARMMaterializeGV for Indirect calls

Recent shouldAssumeDSOLocal changes (introduced by 961f31d8ad14c66)
do not take in consideration the relocation model anymore.  The ARM
fast-isel pass uses the function return to set whether a global symbol
is loaded indirectly or not, and without the expected information
llvm now generates an extra load for following code:

```
$ cat test.ll
@__asan_option_detect_stack_use_after_return = external global i32
define dso_local i32 @main(i32 %argc, i8** %argv) #0 {
entry:
  %0 = load i32, i32* @__asan_option_detect_stack_use_after_return,
align 4
  %1 = icmp ne i32 %0, 0
  br i1 %1, label %2, label %3

2:
  ret i32 0

3:
  ret i32 1
}

attributes #0 = { noinline optnone }

$ lcc test.ll -o -
[...]
main:
        .fnstart
[...]
        movw    r0, :lower16:__asan_option_detect_stack_use_after_return
        movt    r0, :upper16:__asan_option_detect_stack_use_after_return
        ldr     r0, [r0]
        ldr     r0, [r0]
        cmp     r0, #0
[...]
```

And without 'optnone' it produces:
```
[...]
main:
        .fnstart
[...]
        movw    r0, :lower16:__asan_option_detect_stack_use_after_return
        movt    r0, :upper16:__asan_option_detect_stack_use_after_return
        ldr     r0, [r0]
        clz     r0, r0
        lsr     r0, r0, #5
        bx      lr

[...]
```

This triggered a lot of invalid memory access in sanitizers for
arm-linux-gnueabihf.  I checked this patch both a stage1 built with
gcc and a stage2 bootstrap and it fixes all the Linux sanitizers
issues.

Reviewed By: MaskRay

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

[RISCV] Have customLegalizeToWOp truncate to the original type instead of i32 now that we use it for i8/i16 as well.

239cfbccb0509da1a08d9e746706013b732e646b add support for legalizing
i8/i16 UDIV/UREM/SDIV to use *W instructions. So we need to truncate
to i8/i16 if we're legalizing one of those.

[mlir] sret and byval now require a type argument when constructed.

Fixes the LLVM code gen bugs and adds the missing tests.

Reviewed By: ftynse

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

Reland "[lit] Use os.cpu_count() to cleanup TODO"

The initial problem with the remaining bot config was resolved.

We can now use Python3.  Let's use `os.cpu_count()` to cleanup this
helper.

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

[lldb][NFC] Another attempt to fix GCC 5.x compilation

37510f69b4cb8d76064f108d57bebe95984a23ae tried to fix GCC 5.x compilation
by making the enum which is used as a unordered_map key unscoped. However it
seems that in GCC 5.x, enum keys are not supported *at all* in unordered_maps
(at least that's what some trial&error on godbolt tells me). This updates the
workaround to just use an int until GCC 5.x support is dropped.

[mlir] Set CUDA/ROCm context before creating resources.

The current context is thread-local state, and in preparation of GPU async execution (on multiple threads) we need to set the context before calling API that create resources.

Reviewed By: herhut

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

AMDGPU: Fix redundant FP spilling/assert in some functions

If a function has stack objects, and a call, we require an FP. If we
did not initially have any stack objects, and only introduced them
during PrologEpilogInserter for CSR VGPR spills, SILowerSGPRSpills
would end up spilling the FP register as if it were a normal
register. This would result in an assert in a debug build, or
redundant handling of the FP register in a release build.

Try to predict that we will have an FP later, although this is ugly.

AMDGPU: Add assertion to determineCalleeSaves

Make sure this isn't getting called multiple times. I was surprised we
were modifying the function here, which I think is a bit questionable.

[OpenMP][deviceRTLs] Build the deviceRTLs with OpenMP instead of target dependent language

From this patch (plus some landed patches), `deviceRTLs` is taken as a regular OpenMP program with just `declare target` regions. In this way, ideally, `deviceRTLs` can be written in OpenMP directly. No CUDA, no HIP anymore. (Well, AMD is still working on getting it work. For now AMDGCN still uses original way to compile) However, some target specific functions are still required, but they're no longer written in target specific language. For example, CUDA parts have all refined by replacing CUDA intrinsic and builtins with LLVM/Clang/NVVM intrinsics.
Here're a list of changes in this patch.
1. For NVPTX, `DEVICE` is defined empty in order to make the common parts still work with AMDGCN. Later once AMDGCN is also available, we will completely remove `DEVICE` or probably some other macros.
2. Shared variable is implemented with OpenMP allocator, which is defined in `allocator.h`. Again, this feature is not available on AMDGCN, so two macros are redefined properly.
3. CUDA header `cuda.h` is dropped in the source code. In order to deal with code difference in various CUDA versions, we build one bitcode library for each supported CUDA version. For each CUDA version, the highest PTX version it supports will be used, just as what we currently use for CUDA compilation.
4. Correspondingly, compiler driver is also updated to support CUDA version encoded in the name of bitcode library. Now the bitcode library for NVPTX is named as `libomptarget-nvptx-cuda_[cuda_version]-sm_[sm_number].bc`, such as `libomptarget-nvptx-cuda_80-sm_20.bc`.

With this change, there are also multiple features to be expected in the near future:
1. CUDA will be completely dropped when compiling OpenMP. By the time, we also build bitcode libraries for all supported SM, multiplied by all supported CUDA version.
2. Atomic operations used in `deviceRTLs` can be replaced by `omp atomic` if OpenMP 5.1 feature is fully supported. For now, the IR generated is totally wrong.
3. Target specific parts will be wrapped into `declare variant` with `isa` selector if it can work properly. No target specific macro is needed anymore.
4. (Maybe more...)

Reviewed By: JonChesterfield

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

[lldb] Remove unused ThreadPlanStack::GetStackOfKind (NFC)

This function isn't used.

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

[clangd] Add std::size_t to StdSymbol mapping

This is a common symbol that's missing from our mapping because
cppreference yields multiple headers.

Add it manually by picking cstddef to prevent insertion of some stdlib-internal
headers instead.

Fixes https://github.com/clangd/clangd/issues/666.

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

[mlir] Add Python bindings for IntegerSet

This follows up on the introduction of C API for the same object and is similar
to AffineExpr and AffineMap.

Reviewed By: stellaraccident

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

[LoopVectorize] add test for fmin/fmax FMF propagation; NFC

The existing test has less FMF than we might expect if
our FMF was fixed (on all FP values), so this additional
test is intended to check propagation in a more "normal"
example.

[LoopUtils] do not initialize Cmp predicate unnecessarily; NFC

The switch must set the predicate correctly; anything else
should lead to unreachable/assert.

I'm trying to fix FMF propagation here and the callers,
so this is a preliminary cleanup.

Fix null dereference static analysis warning. NFCI.

Replace cast_or_null<> with cast<> as we immediately dereference the pointer afterward so we're not expecting a null pointer.

[AMDGPU] HSAMD::fromString - replace std::string arg with StringRef. NFCI.

Removes an unnecessary chain of StringRef -> std::string -> StringRef conversions

[NFC] Disallow unused prefixes under clang/test/CodeGen

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

[mlir][nfc] Move `getInnermostParallelLoops` to SCF/Transforms/Utils.h.

[Sema] diagnoseEquivalentInternalLinkageDeclarations - assert for non-null NamedDecl. NFCI.

Fixes clang static analysis warnings.

[AMDGPU] Fix null-dereference static analysis warnings. NFCI.

Avoid repeated calls to isZeroValue() and check for a null pointer before dereferencing a dyn_cast<>.

[libomptarget][NFC] Fixed obsolete function names in comments

AMDGPU: Clear IsSSA property in SIFormMemoryClauses

Fixes verifier error when writing MIR testcases

[LoopUnswitch] Avoid partially unswitching too aggressively.

This patch adds additional checks to avoid partial unswitching
in cases where it won't be profitable, e.g. because the path directly
exits the loop anyways.

[LoopUnswitch] Add some additional tests.

Add a few additional tests where partial unswitching is not really
profitable and should be avoided.

Fix signed/unsigned comparison warning. NFCI.

[CostModel] Handle CTLZ and CCTZ in getTypeBasedIntrinsicInstrCost

Reviewed By: dmgreen

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

[AMDGPU] Add IntrWillReturn to three intrinsics

None of these can terminate a wave or lane.
With these, all intrinsic are IntrWillReturn except those that change
exec or can terminate the wave.

Not marking intrinsics as WillReturn may prevent optimizations in the
future: https://lists.llvm.org/pipermail/llvm-dev/2021-January/148047.html

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

[AMDGPU] Fix use of HasModifiers in VopProfile

HasModifiers should be true if at least one modifier is used.
This should make the use of this field bit more consistent.

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

[Passes] Run peeling as part of simple/full loop unrolling.

Loop peeling removes conditions from loop bodies that become invariant
after a small number of iterations. When triggered, this leads to fewer
compares and possibly PHIs in loop bodies, enabling further
optimizations. The current cost-model of loop peeling should be quite
conservative/safe, i.e. only peel if a condition in the loop becomes
known after peeling.

For example, see PR47671, where loop peeling enables vectorization by
removing a PHI the vectorizer does not understand. Granted, the
loop-vectorizer could also be taught about constant PHIs, but loop
peeling is likely to enable other optimizations as well.

This has an impact on quite a few benchmarks from
MultiSource/SPEC2000/SPEC2006 on X86 with -O3 -flto, for example

    Same hash: 186 (filtered out)
    Remaining: 51
    Metric: loop-vectorize.LoopsVectorized

    Program                                        base   patch  diff
     test-suite...ve-susan/automotive-susan.test     8.00   9.00 12.5%
     test-suite...nal/skidmarks10/skidmarks.test    35.00  31.00 -11.4%
     test-suite...lications/sqlite3/sqlite3.test    41.00  43.00  4.9%
     test-suite...s/ASC_Sequoia/AMGmk/AMGmk.test    25.00  26.00  4.0%
     test-suite...006/450.soplex/450.soplex.test    88.00  89.00  1.1%
     test-suite...TimberWolfMC/timberwolfmc.test   120.00 119.00 -0.8%
     test-suite.../CINT2006/403.gcc/403.gcc.test   215.00 216.00  0.5%
     test-suite...006/447.dealII/447.dealII.test   957.00 958.00  0.1%
     test-suite...ternal/HMMER/hmmcalibrate.test    75.00  75.00  0.0%

    Same hash: 186 (filtered out)
    Remaining: 51
    Metric: loop-vectorize.LoopsAnalyzed

    Program                                        base    patch   diff
     test-suite...ks/Prolangs-C/agrep/agrep.test   440.00  434.00  -1.4%
     test-suite...nal/skidmarks10/skidmarks.test   312.00  308.00  -1.3%
     test-suite...marks/7zip/7zip-benchmark.test   6399.00 6323.00 -1.2%
     test-suite...lications/minisat/minisat.test   134.00  135.00   0.7%
     test-suite...rks/FreeBench/pifft/pifft.test   295.00  297.00   0.7%
     test-suite...TimberWolfMC/timberwolfmc.test   1879.00 1869.00 -0.5%
     test-suite...pplications/treecc/treecc.test   689.00  691.00   0.3%
     test-suite...T2000/300.twolf/300.twolf.test   1593.00 1597.00  0.3%
     test-suite.../Benchmarks/Bullet/bullet.test   1394.00 1392.00 -0.1%
     test-suite...ications/JM/ldecod/ldecod.test   1431.00 1429.00 -0.1%
     test-suite...6/464.h264ref/464.h264ref.test   2229.00 2230.00  0.0%
     test-suite...lications/sqlite3/sqlite3.test   2590.00 2589.00 -0.0%
     test-suite...ications/JM/lencod/lencod.test   2732.00 2733.00  0.0%
     test-suite...006/453.povray/453.povray.test   3395.00 3394.00 -0.0%

Note the -11% regression in number of loops vectorized for skidmarks. I
suspect this corresponds to the fact that those loops are gone now (see
the reduction in number of loops analyzed by LV).

Reviewed By: lebedev.ri

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

[ORC] Attempt to auto-claim responsibility for weak defs in ObjectLinkingLayer.

Compilers may insert new definitions during compilation, E.g. EH personality
function pointers, or named constant pool entries. This commit causes
ObjectLinkingLayer to attempt to claim responsibility for all weak definitions
in objects as they're linked. This is always safe (first claimant for each
symbol is granted responsibility, subsequent claims are rejected without error)
and prevents compiler-injected symbols from being dead-stripped (which they
will be if they remain unclaimed by anyone).

This change was motivated by errors seen by an out-of-tree client while testing
eh-frame support in JITLink ELF/x86-64: IR containing exceptions didn't define
DW.ref.__gxx_personality_v0 (since it's added by CodeGen), and this caused
DW.ref.__gxx_personality_v0 to be dead-stripped leading to linker failures.

No test case yet: We won't have a way to test in-tree until we enable JITLink
for lli on Linux.

Revert "[flang] Search for #include "file" in right directory"

This reverts commit d987b61b1dce9948801ac37704477e7c257100b1.

As pointed out in https://reviews.llvm.org/D95388, the reverted commit
causes build failures in the following Flang buildbots:
  * http://lab.llvm.org:8011/#/builders/32/builds/2642
  * http://lab.llvm.org:8011/#/builders/33/builds/2131
  * http://lab.llvm.org:8011/#/builders/135/builds/1473
  * http://lab.llvm.org:8011/#/builders/66/builds/1559
  * http://lab.llvm.org:8011/#/builders/134/builds/1409
  * http://lab.llvm.org:8011/#/builders/132/builds/1817
I'm guessing that the patch was only tested with
`FLANG_BUILD_NEW_DRIVER=Off` (i.e. the default). The builders listed
above set `FLANG_BUILD_NEW_DRIVER` to `On`.

Although fixing the build is relatively easy, the reverted patch
modifies the behaviour of the frontend, which breaks driver tests. In
particular, in https://reviews.llvm.org/D93453 support for `-I` was
added that depends on the current behaviour. The reverted patch
changes that behaviour. Either the tests have to be updated or the
change fine-tuned.

Remove requirement for -maltivec to be used when using -mabi=vec-extabi or -mabi=vec-default when not using vector code

The previous implementation required that `-maltivec` be specified when using either `-mabi=vec-extabi` or `-mabi=vec-default`, this patch removes that requirement.

Reviewed By: cebowleratibm

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

[ORC] Fix debug logging message.

[JITLink][ELF/x86-64] When building PLT stub, use -4 offset for PCRel32.

This is required for ELF where PCRel32 doesn't implicitly subtract 4.

No test case yet: I haven't figured out a good way to test stub
generation -- this may required extensions to jitlink-check.

[LIBOMPTARGET]FIX define declaration, NFC

Fixed declaration of define by adding a comma symbol. Required to fix build without profiling.

[mlir] drop unused statics

[LLD][ELF][AArch64] Add support for R_AARCH64_LD64_GOTPAGE_LO15 relocation

It is not used by LLVM, but GCC might generates it when compiling
with -fpie, as indicated by PR#40357 [1].

[1] https://bugs.llvm.org/show_bug.cgi?id=40357

[AMDGPU][MC] Refactored exp tgt handling

Summary:
- Separated tgt encoding from parsing;
- Separated tgt decoding from printing;
- Improved errors handling;
- Disabled leading zeroes in index. The following code is no longer accepted: exp pos00 v3, v2, v1, v0

Reviewers: arsenm, rampitec, foad

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

[mlir] Async: add a separate pass to lower from async to async.coro and async.runtime

Depends On D95000

Move async.execute outlining and async -> async.runtime lowering into the separate Async transformation pass

Reviewed By: mehdi_amini

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

[SVE] Fix some logical arithmetic tests

There were some right-shift tests in

  CodeGen/AArch64/sve-int-arith-imm.ll

that were being folded away because we were shifting all the bits
out to the right. I've updated the tests to ensure this doesn't
happen.

Revert "[clang-format] add case aware include sorting"

This reverts commit 3395a336b02538d0bb768ccfae11c9b6151b102e as there was a post-merge doubt about option naming and type.

[mlir:async] Use ODS to define async types

Depends On D94923

Migrate Async dialect to ODS `TypeDef`

Reviewed By: ftynse, rriddle

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

[yaml2obj][obj2yaml] - Improve how we set/dump the sh_entsize field.

We already set the `sh_entsize` field in a single place
for all non-implicit sections.

This patch reorders the logic slightly and with it
we finally have the only one place where the `sh_entsize` is set.

obj2yaml will not dump the `EntSize` key for `SHT_DYNSYM/SHT_SYMTAB` sections anymore,
when the value of `sh_entsize` is equal to `sizeof(Elf_Sym)`

Note that this also seems revealed an issue in llvm-objcopy:
Previously yaml2obj set the `sh_entsize` for the `.symtab` section to 0x18,
now we it sets it for `SHT_SYMTAB` sections, i.e. by type.
But the `llvm-objcopy/ELF/only-keep-debug.test` has a `.symtab` section of type `SHT_STRTAB`,
and now yaml2obj sets the `sh_entsize` to 0 for it.
I had to update the corresponding check lines for `ES`, but the behavior of
`llvm-objcopy` should be fixed instead I think.
I've added a TODO and a comment.

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

[llvm-nm] Silence a gcc warning about a stray semicolon. NFC.

[update_llc_test_checks] Support AVR

Reviewed By: arichardson

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

[LLDB][test] - Fix test after yaml2obj change.

D95354 started to set the sh_link field for SHT_SYMTAB sections.
Previously it was set for symbol tables basing on their names (e.g. ".symtab").

This test now crashes see:
http://lab.llvm.org:8011/#/builders/68/builds/5911

I updated it to restore the old behavior.

[clang][cli] Port GPU-related language options to marshalling system

Port some GPU-related language options to the marshalling system for automatic command line parsing and generation.

Reviewed By: dexonsmith

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

[yaml2obj] - Refine how we set the sh_link field. NFCI.

This refactors the logic that sets the `sh_link` field.
With this patch we set it in a single place for all sections.

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

[llvm-nm][ELF] - Use @@ prefix when printing default versions.

llvm-readelf prints default versions with `@@` prefix.
This patch does the same for llvm-nm.

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

[clangd] Add include-fixer fixit for no_member_template diagnostic.

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

[libObject,llvm-readelf/obj] - Don't use @@ when printing versions of undefined symbols.

A default version (@@) is only available for defined symbols.

Currently we use "@@" for undefined symbols too.
This patch fixes the issue and improves our test case.

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

[RISCV] Adjust RISCVInstrInfoVSDPatterns.td for different pseudo instructions for different FPR.

Move the Suffix string into the VTypeInfo class so we don't need a helper class to get to it.

Adjust pseudo naming scheme for FPRs to put F16/F32/F64 in
place of F in the pseudo instruction name rather than as a suffix.
This avoids special cases like VFMERGE from the original patch.

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

[NFC] Refine some uninitialized used variables.

These warning are reported by static code analysis tool: Klocwork

Reviewed By: pengfei

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

[clangd] Fix filename completion at the end of file

Fixes https://github.com/clangd/clangd/issues/433

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

[clang][cli] Accept strings instead of options in ImpliedByAnyOf

To be able to refer to constant keypaths (e.g. `defvar cplusplus = LangOpts<"CPlusPlus">`) inside `ImpliedByAnyOf`, let's accept strings instead of `Option` instances.

This somewhat weakens the guarantees that we're referring to an existing (option) record, but we can still use the option.KeyPath syntax to simulate this.

Reviewed By: dexonsmith

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

[clang][cli] Port GNU language options to marshalling system

Port some GNU-related language options to the marshalling system for automatic command line parsing and generation.

Reviewed By: dexonsmith

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

[clang][cli] Store LangStandard::Kind in LangOptions

The `LangStandard::Kind` parsed from command line arguments is used to set up some `LangOption` defaults, but isn't stored anywhere.

To be able to generate `-std=` (in future patch), we need `CompilerInvocation` to not forget it.

This patch demonstrates another use-case: using `LangStd` to set up defaults of marshalled options.

Reviewed By: dexonsmith

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

[RISCV] Define different pseudo instructions for different FPR.

When spilling, the spill size will depend on the size of register class.
For .vf vector instructions, it may spill the floating point scalar
argument. In order to use the correct load/store instructions for
spilling, we need to provide the correct floating point register class
for the .vf vector pseudo instructions.

In this commit, we define the .vf pseudo instructions as three
different kinds of pseudo instructions for half/float/double. For
example, PseudoVFADD_M1 will become as PseudoVFADD_F16_M1,
PseudoVFADD_F32_M1, and PseudoVFADD_F64_M1.

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

[clang][cli] NFC: Simplify BoolOption API

The `Bool{,F,G}Option` TableGen classes were designed after `Opt{In,Out}FFlag`, which put marshalling info on only one of the boolean options. To encode which record is supposed to carry the marshalling info (and be visible on -cc1 command-line), we used the `ChangedBy` and `ResetBy` classes.

However, we need to put marshalling info on both records anyways (see D93008 for details). This means we don't really need the distinction between `ChangedBy/ResetBy + BoolOption` and `FlagDef + BoolOptionBase` anymore.

This patch reduces the number of ways one can encode the marshalling information for pairs of boolean flags. Regardless of whether the key path value defaults to a statically known boolean, or a result of an expression, one can always use the new `BoolOption` and `PosFlag<SetTrue>, NegFlag<SetFalse>` syntax.

Reviewed By: dexonsmith

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

Add vp2intersect to AVX512 dialect.

Adds vp2intersect to the AVX512 dialect and defines a lowering to the
LLVM dialect.

Author: Matthias Springer <springerm@google.com>

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

Revert "[WebAssembly] MC layer writes table symbols to object files"

This reverts commit d806618636f8a82bfc3f620e1fad83af4d2a2575.
Review: https://reviews.llvm.org/D92215

We had issues where older versions of wasm-ld were crashing on object
files containing a table symbol.  We decided that the best strategy
going forward is to only generate these symbol if refernece types is
enabled.  Without reference types enabled we should never geneate a
table symbol or a TABLE_NUMBER relocation.

This revert is in addition to the one already reverted in
https://reviews.llvm.org/D95005.

The plan is to re-land these in updated form after the llvm 12 branch.

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

[Object][WebAssembly] Update format of error messages

Error message should start with lowercase in accordance with
https://llvm.org/docs/CodingStandards.html#error-and-warning-messages

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

[mlir][Python] Fix comments of 'getCapsule' and 'createFromCapsule'

The `getCapsule` and `createFromCapsule` comments incorrectly state the `PyMlirContext` and `MlirContext` in `PyLocation`, `PyAttribute`, and `PyType` classes.

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

[OpenMP] Add source location information to the libomptarget profile

In much of the libomptarget interface we have an ident_t object now, if
it is not null we can use it to improve the profile output. For now, we
simply use the ident_t "source information string" as generated by the
FE.

Reviewed By: tianshilei1992

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

[OpenMP][FIX] Enforce a function boundary for a new data environment

Whenever we enter a new OpenMP data environment we want to enter a
function to simplify reasoning. Later we probably want to remove the
entire specialization wrt. the if clause and pass the result to the
runtime, for now this should fix PR48686.

Reviewed By: ABataev

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

[RISCV] Update V extension to v1.0-draft 08a0b464.

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

[RISCV] Implement vlsegff intrinsics.

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

[AMDGPU] Forward-declare MachineIRBuilder (NFC)

AMDGPULegalizerInfo.h needs MachineIRBuilder but relies on a forward
declaration of MachineIRBuilder in LegalizerInfo.h.  This patch adds a
forward declaration right in AMDGPULegalizerInfo.h.

While we are at it, this patch removes the one in LegalizerInfo.h,
where it is unnecessary.

[StackSafety] Use ListSeparator (NFC)

[TableGen] Use llvm::append_range (NFC)

[OpenMP] Added the support for hidden helper task in RTL

The basic design is to create an outer-most parallel team. It is not a regular team because it is only created when the first hidden helper task is encountered, and is only responsible for the execution of hidden helper tasks.  We first use `pthread_create` to create a new thread, let's call it the initial and also the main thread of the hidden helper team. This initial thread then initializes a new root, just like what RTL does in initialization. After that, it directly calls `__kmpc_fork_call`. It is like the initial thread encounters a parallel region. The wrapped function for this team is, for main thread, which is the initial thread that we create via `pthread_create` on Linux, waits on a condition variable. The condition variable can only be signaled when RTL is being destroyed. For other work threads, they just do nothing. The reason that main thread needs to wait there is, in current implementation, once the main thread finishes the wrapped function of this team, it starts to free the team which is not what we want.

Two environment variables, `LIBOMP_NUM_HIDDEN_HELPER_THREADS` and `LIBOMP_USE_HIDDEN_HELPER_TASK`, are also set to configure the number of threads and enable/disable this feature. By default, the number of hidden helper threads is 8.

Here are some open issues to be discussed:
1. The main thread goes to sleeping when the initialization is finished. As Andrey mentioned, we might need it to be awaken from time to time to do some stuffs. What kind of update/check should be put here?

Reviewed By: jdoerfert

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

Revert "[libomptarget][cuda] Gracefully handle missing cuda library"

This reverts commit fafd45c01f3a49a40b09a31e9ea82efc87f3ab35.

[Test][AArch64] Add s32 legalizer test for UADDE/USUBE

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

[Test][AArch64] Move overflow add/sub tests to their own file. NFC

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

[JITLink] Disable ELF_ehframe_basic.s test on Windows.

This test is failing on some windows bots with an error claiming that it is not
producing output. This appears to be a spurious failure, so I'm disabling on
windows while we investigate rather than reverting.