Reviewed By: foad

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

Reviewed By: kadircet

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

Add a builder that takes a callback to construct the body of the op.

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

[AMDGPU] Turn off pass to rewrite partially used virtual superregisters after RenameIndependentSubregs pass with registers of minimal size.

There is a failure with this pass in the case when target register class for a subregister isn't known from instruction description (for ex. COPY).
Currently in this situation the RC is obtained using TargetRegisterInfo::getSubRegisterClass but in general it's not working.

In order to fix this two things should be done:
1. Stop processing a subregister if the target register class is unknown (conservative approach)
2. Improve deduction of subregister' target register class (i.e by processing COPY chain)

I was going to implement point 1 but my tests use implicit operands for S_NOP and they don't have associated target register class and all tests fail.
Therefore I decided to turn off the pass now, implement point 1 and fix my tests.

Reviewed By: arsenm, #amdgpu

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

This will fix unused-include false positive.

```
// primary.h
namespace ns {
template<class T1, class T2> class Z {}; // primary template
}

// partial.h
namespace ns {
template<class T> class Z<T, T*> {};     // partial specialization
}

// main.cpp

using ns::Z; // refs to the primary
void k() {
  Z<int, int*> z; // use the partial specialization
}
```

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

Expose the respective patterns as a transform op.

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

with multiple declarations followed by a colon.

Fixes #63010

Reviewed By: shafik

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

This reverts commit 57882fe7.
This reverts commit 74b0ac57.

Breaks various build bots.

Consider only targets where `MCAsmInfo::ExceptionsType == ExceptionHandling::None`
and that support CFI (when `MCAsmInfo::UsesCFIForDebug` is set to true):
currently, only AMDGPU.

This patch enables the emission of CFI information in the .eh_frame
section when the uwtable attribute is present on a function.

Before, we could generate CFI information for debugging puproses only.

This patch prepares AMDGPU to support collecting GPU stack traces in the future.

I did a first implementation (https://reviews.llvm.org/D139024)
but at the time I had not realized that no other platform used
`UsesCFIForDebug`.

Reviewed By: scott.linder

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

This patch splits the GlobalISelEmitter.cpp file, which imports DAG ISel patterns for GISel, into separate "GISelMatchTable.h/cpp" files.

The main motive is readability & maintainability. GlobalISelEmitter.cpp was about 6400 lines of mixed code, some bits implementing the match table codegen, some others dedicated to importing DAG patterns.

Now it's down to  2700 + a 2150 header + 2000 impl.
It's a tiny bit more lines overall but that's to be expected - moving
inline definitions to out-of-line, adding comments in the .cpp, etc. all of that takes additional space, but I think the tradeoff is worth it.

I did as little unrelated code changes as possible, I would say the biggest change is the introduction of the `gi` namespace used to prevent name conflicts/ODR violations with type common names such as `Matcher`.
It was previously not an issue because all of the code was in an anonymous namespace.

This moves all of the "match table" code out of the file, so predicates,
rules, and actions are all separated now. I believe this helps separating concerns, now `GlobalISelEmitter.cpp` is more focused on importing DAG patterns into GI, instead of also containing the whole match table internals as well.

Note: the new files have a "GISel" prefix to make them distinct from the other "GI" files in the same folder, which are for the combiner.

Reviewed By: aemerson

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

This patch adds in CMake option LLVM_ENABLE_LLVM_LIBC which when set to
true automatically builds LLVM libc in overlay mode and links all
generated executables against the libc overlay. This is intended to
somewhat mirror the LLVM_ENABLE_LIBCXX flag.

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

No need to "error" on unsupported architectures, since we technically
only care where the macro is used. If the macro is undefined, and used,
the compiler will producer an error anyway.

This fixes build on Windows, where none of these macros should be used.

Rework Linux (and *BSD) interceptors to allow for up to 3 (2 for *BSD)
simultaneous interceptors. See code comments for details.

The main motivation is to support new sampling sanitizers (in the spirit
of GWP-ASan), that have to intercept few functions. Unfortunately, the
reality is that there are user interceptors that exist in the wild.

To support foreign user interceptors, foreign dynamic analysis
interceptors, and compiler-rt interceptors all at the same time,
including any combination of them, this change enables up to 3
interceptors on Linux (2 on *BSD).

Reviewed By: dvyukov, MaskRay, vitalybuka

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

A multiple (int64_t) can optionally be specified for every padding dimension.

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

The implementation is based on `ValueBoundsOpInterface` to compute upper bounds for tensor dim sizes. It is not necessary to skip over certain ops and reify shape dims; `ValueBoundsOpInterface` already takes care of that.

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

Fixes: https://github.com/llvm/llvm-project/issues/62873

Reviewed By: nikic

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

struct VectorInfo manages resources such as dynamically allocated memory, it's generally a good practice to either implement a custom copy constructor or disable the default one

Reviewed By: kazu

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

class Array manages resources such as dynamically allocated memory, it's generally a good practice to either implement a custom copy constructor or disable the default one.

Reviewed By: pengfei

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

Reviewed By: pengfei

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

Reviewed By: pengfei

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

Reviewed By: pengfei

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

Reviewed By: aprantl

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

Reviewed By: JamesNagurne

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

This PR allows function's cfg to be viewed/printed even if the function
has optnone attribute.

Reviewed By: MaskRay

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

Some CPUs do not allow memory accesses to be unaligned, e.g. 2k1000la
who uses the la264 core on which misaligned access will trigger an
exception.

In this patch, a backend feature called `ual` is defined to decribe
whether the CPU supports unaligned memroy accesses. And this feature
can be toggled by clang options `-m[no-]unaligned-access` or the
aliases `-m[no-]strict-align`. When this feature is on,
`allowsMisalignedMemoryAccesses` sets the speed number to 1 and returns
true that allows the codegen to generate unaligned memory access insns.

Clang options `-m[no-]unaligned-access` are moved from `m_arm_Features_Group`
to `m_Group` because now more than one targets use them. And a test
is added to show that they remain unused on a target that does not
support them. In addition, to keep compatible with gcc, a new alias
`-mno-strict-align` is added which is equal to `-munaligned-access`.

The feature name `ual` is consistent with linux kernel [1] and the
output of `lscpu` or `/proc/cpuinfo` [2].

There is an `LLT` variant of `allowsMisalignedMemoryAccesses`, but
seems that curently it is only used in GlobalISel which LoongArch
doesn't support yet. So this variant is not implemented in this patch.

[1]: https://github.com/torvalds/linux/blob/master/arch/loongarch/include/asm/cpu.h#L77
[2]: https://github.com/torvalds/linux/blob/master/arch/loongarch/kernel/proc.c#L75

Reviewed By: xen0n

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

Compares write a mask result. Min/max write a full result. This
makes them sufficiently different to have their own classes.

Reviewed By: pcwang-thead

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

Fix undefined behavior of left shifting signed integer in exp2f.cpp.

Reviewed By: sivachandra

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

This new representation means that a valid command line option may
potentially be used directly as a multilib flag without any translation.

To indicate that a flag is required not to be present, its first
character is replaced with '!', which is intended for consistency with
the logical not operator in many programming languages.

Reviewed By: simon_tatham

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

Decouple the interface of the MultilibBuilder flag method from how flags
are stored internally. Likewise change the addMultilibFlag function.

Currently a multilib flag like "-fexceptions" means a multilib is
*incompatible* with the -fexceptions command line option, which is
counter-intuitive. This change is a step towards changing this scheme.

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

`V1 >> V2 u<= V1` for any V1, V2

This works for lshr and any div's that are changed to lshr's

This fixes issues in clang and rustc:
https://github.com/llvm/llvm-project/issues/62441
https://github.com/rust-lang/rust/issues/110971

Reviewed By: goldstein.w.n

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

The TODO was left there to verify that Assign() runtime handles
overlaps of allocatable components. It did not, and this change-set
fixes it. Note that the same Assign() issue can be reproduced
without HLFIR. In the following example the LHS would be reallocated
before value of RHS (essentially, the same memory) is read:
```
program main
  type t1
     integer, allocatable :: a(:)
  end type t1
  type(t1) :: x, y
  allocate(x%a(10))
  do i =1,10
     x%a(i) = 2*i
  end do
  x = x
  print *, x%a
  deallocate(x%a)
end program main
```

The test's output would be incorrect (though, this depends on the memory
reuse by malloc):
0 0 0 0 10 12 14 16 18 20

It is very hard to add a Flang unittest exploiting derived types.

Reviewed By: klausler

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

[Hexagon,Lanai,LoongArch,Sparc] Migrate to new encodeInstruction that uses SmallVectorImpl<char>. NFC

The LoongArch ELF psABI document has changed location and versioning
scheme; this revision is v2.10 in the old scheme. Notably this revision
brings initial capability of linker relaxation to LoongArch.

Reviewed By: SixWeining, MaskRay

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

Close https://github.com/llvm/llvm-project/issues/63022

This is the following of https://reviews.llvm.org/D135550, which is
discussed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
In my imagination, we could fix the issue fundamentally after we
introduces new memory kind thread id. But I am not very sure if we can
fix the issue fundamentally in time.

Besides that, I think the correctness is the most important. So it
should not be bad to land this given it is innocent.

Reviewed By: nikic

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