Implement them on top of sdiv/udiv, similar to what we do for integer
types.

Potential future work: implementing i8/i16 srem/urem, optimizations for
constant divisors, optimizing the mul+sub to mls.

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

This has two advantages: one, it's simpler, and two, it doesn't require
heroic pattern matching with scalable vectors.

Also includes a small fix to DataLayout to allow the scalable vector
testcase to work correctly.

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

This is the followup to D77647 which implements handling for the new
R_AARCH64_PLT32 relocation type in lld. This relocation would benefit the
PIC-friendly vtables feature described in D72959.

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

This matches the equivalent flag implemented in GNU linkers, see
https://sourceware.org/pipermail/binutils/2020-June/111685.html for
the associated discussion.

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

Summary:
- Add product names for some processors.
- Correct XNACK support for a processor.

Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, kerbowa, llvm-commits

Tags: #llvm

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

other late-parsed class component handling.

No functionality change intended.

Currently, section indices may be passed uninitialized by value if
writing the section fails. Removes section indices form class
initialization and returns them from the write{Code,Data}Section
function calls instead.

Patch by Gui Andrade!

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

Note that this does not mean that check-mlir will run check-mlir-integration
tests for all configurations. You still need to do a set up with the flag
MLIR_INCLUDE_INTEGRATION_TESTS set to ON in order to activate the integration test.

Reviewed By: jpienaar

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

Unused since r255423 / D15140 /  4e52d6f8

Found indirectly by assessing -debug-info-kind=constructors and
observing the EHPadEndScope type was never emitted because the
constructor is never called. (all credit to Amy Huang for identifying
this issue)

Fixes error: invalid operands to binary expression ('llvm::StringRef'
and 'const char [6]')

This patch adds tests for folds of ADDIs into load/stores, focusing on
load/stores with nonzero offsets. When the offset is nonzero we currently
don't do the fold. A follow-up patch will improve on that.

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

This is a set of type building models that is specific to the lowering
process. It provides the mechanism of mapping C(++) header file interfaces
to the MLIR+FIR type system.

It also provides some macros to build a constexpr evaluated table to
runtime functions. This code is used to build the interface tables to
various runtime support libraries.

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

LDRD and STRD along with UBFX and SBFX are selected from DAGToDAG
transforms, so do not have tblgen patterns. They don't get marked as
having side effects so cannot be scheduled as efficiently as you would
like.

This specifically marks then as not having side effects.

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

outer levels as retained rather than omitting their arguments.

This better reflects what's going on (we're performing a substitution
while still inside a template), and in theory is more correct, but I've
not found a testcase where it matters in practice (largely because we
don't allow alias templates to be declared inside a function).

Fixed AST dumping of SubstNonTypeTemplateParm[Pack]Expr to demonstrate
that we're properly substituting through dependent alias templates. (We
can't deduce properly through these yet, but we can at least produce the
right input to template argument deduction.)

No functionality change intended.

Use vector compares for the 1-D case. This approach scales much better
than generating insertion operations, and exposes SIMD directly to backend.

Reviewed By: ftynse

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

Reviewers: efriedma, RKSimon, c-rhodes, fpetrogalli

Reviewed By: fpetrogalli

Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

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

Most useful at the moment for showing where unpredicatable instructions are.

Summary: `nomerge` attribute was added at D78659. So, we can remove the EmptyAsm workaround in ASan the MSan and use this attribute.

Reviewers: vitalybuka

Reviewed By: vitalybuka

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

This wasn't caught by the existing test, but will be covered by the
extended test that's part of D82412.

Summary: As the parent process would return 0 independent of whether the child succeeded, assertions in the child would be ignored.

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: #sanitizers

Tags: #sanitizers

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

InjectTLIMappings fails to preserve the analysis result of GlobalsAA. Not preserving the analysis might affect benchmark performance. This change fixes this issue.

Patch by: Ryan Santhiraraja <rsanthir@quicinc.com>

Reviewers: fpetrogalli, joerg, fhahn

Reviewed By: fhahn

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

Fix test case added by D79830
Rewrite the test case, which did similar thing as builtin-expect.c
does(test generated llvm intrinsic instead of test branch weights).
Currently pass by "-disable-llvm-passes" option.

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

While LLVM does fold this to x+1, GCC does not. As this is hot
code, let's try to avoid that.

According to
https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html
this spurious warning in MSVC has been fixed in Visual Studio 2019
Version 16.4. Let's see if there are any build bots running old
MSVC versions with warnings treated as errors...

Reviewers: efriedma, evgeny777, tejohnson, david-arm, kmclaughlin

Reviewed By: david-arm

Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

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

As pointed out by foad, it's not necessary to work on uint64_t
here. The values used here fit uint8_t.

This patch extends storeIsNoop to also detect stores of 0 to an calloced
object. This basically ports the logic from legacy DSE to the MemorySSA
backed version.

It triggers in a few cases on MultiSource, SPEC2000, SPEC2006 with -O3
LTO:

Same hash: 218 (filtered out)
Remaining: 19
Metric: dse.NumNoopStores

Program                                        base   patch2 diff
 test-suite...CFP2000/177.mesa/177.mesa.test     1.00  15.00 1400.0%
 test-suite...6/482.sphinx3/482.sphinx3.test     1.00  14.00 1300.0%
 test-suite...lications/ClamAV/clamscan.test     2.00  28.00 1300.0%
 test-suite...CFP2006/433.milc/433.milc.test     1.00   8.00 700.0%
 test-suite...pplications/oggenc/oggenc.test     2.00   9.00 350.0%
 test-suite.../CINT2000/176.gcc/176.gcc.test     6.00   6.00  0.0%
 test-suite.../CINT2006/403.gcc/403.gcc.test    NaN   137.00  nan%
 test-suite...libquantum/462.libquantum.test    NaN     3.00  nan%
 test-suite...6/464.h264ref/464.h264ref.test    NaN     7.00  nan%
 test-suite...decode/alacconvert-decode.test    NaN     2.00  nan%
 test-suite...encode/alacconvert-encode.test    NaN     2.00  nan%
 test-suite...ications/JM/ldecod/ldecod.test    NaN     9.00  nan%
 test-suite...ications/JM/lencod/lencod.test    NaN    39.00  nan%
 test-suite.../Applications/lemon/lemon.test    NaN     2.00  nan%
 test-suite...pplications/treecc/treecc.test    NaN     4.00  nan%
 test-suite...hmarks/McCat/08-main/main.test    NaN     4.00  nan%
 test-suite...nsumer-lame/consumer-lame.test    NaN     3.00  nan%
 test-suite.../Prolangs-C/bison/mybison.test    NaN     1.00  nan%
 test-suite...arks/mafft/pairlocalalign.test    NaN    30.00  nan%

Reviewers: efriedma, zoecarver, asbirlea

Reviewed By: asbirlea

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

Add support for the 34bit relocation R_PPC64_PCREL34 for PC Relative in LLD.

Summary:
This redoes https://reviews.llvm.org/D79726 and fixes two things.
- The logic that determines whether to automatically disconnect during the tear down is not very dumb compared to the original implementation. Each test will determine whether to do that or not.
- The terminate commands and terminate event were being sent after the disconnect response was sent to the IDE. That was not good, as VSCode stops the debug session as soon as it receives a disconnect response. Now, the terminate event and terminateEvents are being executed before the disconnect response is sent. This ensures that any connection between the IDE and lldb-vscode is alive while the terminate commands are executed. Besides, it also allows displaying the output of the terminate commands on the debug console, as it's still alive.

Reviewers: clayborg, aadsm, kusmour, labath

Subscribers: lldb-commits

Tags: #lldb

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

Now that Apple Silicon is a thing, we need to generalize the check.

With the advent of Apple Silicon, checking for the architectures
specifically is not correct anymore. This code is only supposed to
run on embedded devices (iPhones et similia), so mark it accordingly.

Summary: The Pass class exists in both the mlir and the llvm namespaces. Use the fully qualified class name to avoid any ambiguities.

Reviewers: rriddle

Reviewed By: rriddle

Subscribers: mehdi_amini, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, jurahul, msifontes

Tags: #mlir

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

Summary:
Make use of both the - (1) clustered bytes and (2) cluster length, to decide on
the max number of mem ops that can be clustered. On an average, when loads
are dword or smaller, consider `5` as max threshold, otherwise `4`. This
heuristic is purely based on different experimentation conducted, and there is
no analytical logic here.

Reviewers: foad, rampitec, arsenm, vpykhtin

Reviewed By: rampitec

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

Tags: #llvm

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

Reviewers: mikhail.ramalho

Reviewed By: mikhail.ramalho

Subscribers: mehdi_amini, mgorny, mikhail.ramalho, llvm-commits

Tags: #llvm

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

[ELF] Resolve relocations in .debug_* referencing (discarded symbols or ICF folded section symbols) to tombstone values

See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and
https://sourceware.org/pipermail/binutils/2020-May/111357.html for
extensive discussions on a tombstone value.
See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1
(Reserve an address value for "not present") for a DWARF enhancement proposal.

We resolve such relocations to a tombstone value to indicate that the address is invalid.
This solves several problems (the normal behavior is to resolve the relocation to the addend):

* For an empty function in a collected section, a pair of (0,0) can
  terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld
  resolves such a relocation to 1 to avoid the .debug_ranges issue)
* If DW_AT_high_pc is sufficiently large, the address range can collide
  with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 )
* If a text section is folded into another by ICF, we may leave entries
  in multiple CUs claiming ownership of the same range of code, which can
  confuse consumers.
* Debug information associated with COMDAT sections can have problems
  similar to ICF, but is more complex - thus not addressed by this patch.

For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate
entries (invalidating subsequent ranges).
-1 is a reserved value with special meaning (base address selection entry) which can't be used either.
Use -2 instead.

For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX
for 64-bit targets. In the code, we intentionally use
`uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches
SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32)

Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not
short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased.
They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory,
producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.)

Note 1, we have to ignore the addend, because we don't want to resolve
DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap
around to a low address):

  __attribute__((section(".text.x"))) void f1() { }
  __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend

Note 2, if the prevailing copy does not have debugging information while
a non-prevailing copy has (partial debug build), we don't do extra work
to attach debugging information to the prevailing definition.  (clang
has a lot of debug info optimizations that are on-by-default that assume
the whole program is built with debug info).

  clang -c -ffunction-sections a.cc    # prevailing copy has no debug info
  clang -c -ffunction-sections -g b.cc

Reviewed By: dblaikie, avl, jhenderson

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

Summary:
Recently I've noticed that VSCode sometimes doesn't send the terminateDebuggee flag within the disconnectRequest,
even though lldb-vscode sets the terminateDebuggee capability correctly.
This has been causing that inferiors don't die after the debug session ends, and many users have reported issues because of this.

An easy way to mitigate this is to set better default values for the terminateDebuggee field in the disconnect request.
I'm assuming that for a launch request, the default will be true, and for attach it'll be false.

Reviewers: clayborg, labath, aadsm

Subscribers: lldb-commits

Tags: #lldb

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