This requires defining the DIFlag enum from LLVM.

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

Reviewed By: aartbik

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

Reviewed By: aartbik

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

Reviewed By: antiagainst

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

Based on lld/ part of D137338 but reflowed comments.

Not all derived type can be taken as abstract result. The CPTR type
should be treated as return by value so to interoperable with C
functions. Fix the function result rewrite for CPTR type, but it
should be generalized for all derived types. The ABI of
interoperability with C for derived type is architecture dependent,
which should be supported later.

Reviewed By: PeteSteinfeld, jeanPerier

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

The new class helps encapsulate the arguments to `_mlir_ciface_newSparseTensor` so that client code doesn't depend on the details of the API.  (This makes way for the next differential which significantly alters the API.)

Reviewed By: aartbik

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

name.  lldb-dotest.py errors out if two tests have the same filename.

This seems like an anti-pattern to have -Werror on by default:
it is hostile to user as we can't ensure that all of the supported
platforms are warning-free, and any newer compiler could break the build
for a user who does not have a clear actionable way around it.

Reviewed By: GMNGeoffrey, kuhar

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

Vectorization of Linalg's depthwise convolution only supports floating
point types. Previous version assumed floating point operations would
work. This version checks whether the computation is integer or floating
point and adjust the inner loop computation.

Reviewed By: hanchung

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

This found an insertion point bug in access pattern expansion

Reviewed By: bixia

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

ProvenanceAnalysis::relatedCheck was giving different answers depending
on the order in which the pointers were passed.

Specifically, it was returning different values when A and B were both
loads and were both referring to identifiable objects, but only one was
used by a store instruction.

Reviewed By: Peiming

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

For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from
the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template.
This change makes `--` long option diagnostics more convenient.

Reviewed By: lenary

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

While extending the map file to cover unwind info, I realized we had two
issues with our EH_Frame symbols:

1. Their size was not set
2. We would create two EH_Frame symbols per frame when we only needed
   one. This was because the Defined constructor would add the symbol
   itself to InputSection::symbols, but we were also manually appending
   the symbol to that same vector.

Note that ld64 prints "CIE" and "FDE for: <function>" instead of just
"EH_Frame", but I'm punting on that for now unless we discover that
users really depend upon it.

Reviewed By: #lld-macho, Roger

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

Just like ld64 does.

Reviewed By: #lld-macho, Roger

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

The previous map file code left out was modeled after LLD-ELF's
implementation. However, ld64's map file differs quite a bit from
LLD-ELF's. I've revamped our map file implementation so it is better
able to emit ld64-style map files.

Notable differences:
* ld64 doesn't demangle symbols in map files, regardless of whether
  `-demangle` is passed. So we don't have to bother with
  `getSymbolStrings()`.
* ld64 doesn't emit symbols in cstring sections; it emits just the
  literal values. Moreover, it emits these literal values regardless of
  whether they are labeled with a symbol.
* ld64 emits map file entries for things that are not strictly symbols,
  such as unwind info, GOT entries, etc. That isn't handled in this
  diff, but this redesign makes them easy to implement.

Additionally, the previous implementation sorted the symbols so as to
emit them in address order. This was slow and unnecessary -- the symbols
can already be traversed in address order by walking the list of
OutputSections. This brings significant speedups. Here's the numbers
from the chromium_framework_less_dwarf benchmark on my Mac Pro, with the
`-map` argument added to the response file:

             base            diff           difference (95% CI)
  sys_time   2.922 ± 0.059   2.950 ± 0.085  [  -0.7% ..   +2.5%]
  user_time  11.464 ± 0.191  8.290 ± 0.123  [ -28.7% ..  -26.7%]
  wall_time  11.235 ± 0.175  9.184 ± 0.169  [ -19.3% ..  -17.2%]
  samples    16              23

(It's worth noting that map files are written in parallel with the
output binary, but they often took longer to write than the binary
itself.)

Finally, I did further cleanups to the map-file.s test -- there was no
real need to have a custom-named section. There were also alt_entry
symbol declarations that had no corresponding definition. Either way,
neither custom-named sections nor alt_entry symbols trigger special code
paths in our map file implementation.

Reviewed By: #lld-macho, Roger

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

This revision generalizes lowering the sparse_tensor.insert op into actual code that directly operates on the memrefs of a sparse storage scheme. The current insertion strategy does *not* rely on a cursor anymore, with introduces some testing overhead for each insertion (but still proportional to the rank, as before). Over time, we can optimize the code generation, but this version enables us to finish the effort to migrate from library to actual codegen.

Things to do:
(1) carefully deal with (un)ordered and (not)unique
(2) omit overhead when not needed
(3) optimize and specialize
(4) try to avoid the pointer "cleanup" (at HasInserts), and make sure the storage scheme is consistent at every insertion point (so that it can "escape" without concerns).

Reviewed By: Peiming

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

Shift it to where we already check for FusedLoc, which removes the
need to cast multiple times.

This avoids accidentally using the wrong inlined at scope when translating
locations.

llvm-project/mlir/lib/Conversion/NVGPUToNVVM/NVGPUToNVVM.cpp:441:25:
warning: multiple unsequenced modifications to 'asmArgIdx'
[-Wunsequenced]
  ss << "$" << asmArgIdx++ << ",$" << asmArgIdx++ << ";";
                        ^                      ~~

I've:
- Sorted the members of FormatStyle alphabetical. The enums and structs
  are kept close to the member.
- Sorted the yaml io functions, based on the type they operate on.
- Sorted the initializers in getLLVMStyle(), except that penalities are
  kept at the end.
- Sorted the io of FormatStyle, this changes the --dump-config behavior.
- Moved the deprecated options into the only input case, this also
  changes --dump-config, it does not put the not directly used options
  in the .clang-format anymore.
- Sorted the comparisons in operator==.
- Added WhiteSpaceMacros in operator==, I've not actively looked if all
  other members are compared.
- This showed flawed tests (or in my opinion a flawed io operation, but
  that is another discussion and change).

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

Also improve DisplayStrings for array and string types.

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

The pipeline strings have been getting more verbose over time, adding an
alias for the option should help improve the ergonomics a bit.

Reviewed By: rriddle

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

Update the SPIRV `mlir-translate` translations to translate to/from
`spirv.module` instead of `builtin.module`. This simplifies the
translation since the code no longer needs to walk the module looking
for a SPIRV module, however it requires passing `-no-implicit-module` to
all the tests.

Reviewed By: antiagainst

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

D133848 added support for the GCC format of target("..") attributes. The
supported formats to match gcc are:
//  "arch=<arch>" - parsed to features as per -march=..
//  "cpu=<cpu>" - parsed to features as per -mcpu=.., with CPU set to <cpu>
//  "tune=<cpu>" - TuneCPU set to <cpu>
//  "+feature", "+nofeature" - Add (or remove) feature.

We also support the existing formats, previously accepted by clang, for
compatibility with the existing code and intrinsics code:
//  "feature", "no-feature" - Add (or remove) feature.

The clang formats would accept and use internal feature names
("fullfp16"/"neon"/"sve") as opposed to the user facing names
("fp16"/"simd"/"sve"). Usually they use the same names, but can be
different for cases like fp, fullfp16 and mte (among others).

This patch makes the clang format also except the user facing names, by
parsing the features through getArchExtFeature. There is a fallback if
the name is not recognized (like "fullfp16"), where we add the existing
string which should then be checked later for consistency. This allows
the internal names to be used as before, so long as they are recognized
as internal names. (Note that we currently don't have an implementation
of isValidFeatureName. The backend will currently give an error like
"'-sid' is not a recognized feature for this target (ignoring feature)."
This should be improved in a later patch once an implementation of
isValidFeatureName in clang is present).

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

The glibc uses the define to avoid namespace polution on headers
that requires variadic argument, where the inclusion of stdarg.h is
required to obtain the va_list definition.

For such cases only __gnuc_va_list is required.

Reviewed By: MaskRay

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

- This extends the existing helper function 'isWorthFoldingIntoOrrWithLeftShift' into
  'isWorthFoldingIntoOrrWithShift', and encode right-shift imm (the
  encoding of left-shift imm is no-op).

Reviewed By: dmgreen

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

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

This reverts commit 28f9636e.

Bot failure: https://lab.llvm.org/buildbot/#/builders/109/builds/50251

This enables the use of reg+imm addressing modes to match the
non-sret variants of these intrinsics.

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

The extra '?' is useless as it only makes a single letter optional and we can only match the SI64 pattern anyway (V?)CVT(T?)SS2SIrr has a different scheduler def

[mlir][sparse] Add option enable-buffer-initialization to initialize the memory buffers for sparse tensors to support debugging.

Reviewed By: aartbik

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

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

This patch plumbs the AssignmentTrackingPass (AKA declare-to-assign), added in
the previous patch in this set, into the optimisation pipeline from
clang. clang/test/CodeGen/assignment-tracking/assignment-tracking.cpp is the
main test for this patch.

Note: while clang (with the help of the declare-to-assign pass) can now emit
Assignment Tracking metadata, the llvm middle and back ends don't yet
understand it.

Reviewed By: jmorse

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