Summary: courbet

Subscribers: llvm-commits

Tags: #llvm

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

Summary: Prevent InstCombine from removing llvm.assume for which the arguement is true when they have operand bundles with usefull information.

Reviewers: jdoerfert, nikic, lebedev.ri

Reviewed By: jdoerfert

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Summary: This change enable the divergence driven selection for the SEXT DAG opcode.

Reviewers: vpykhtin, rampitec

Reviewed By: vpykhtin

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

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

MLIR supports terminators that have the same successor block with different
block operands, which cannot be expressed in the LLVM's phi-notation as the
block identifier is used to tell apart the predecessors. This limitation can be
worked around by branching to a new block instead, with this new block
unconditionally branching to the original successor and forwarding the
argument. Until now, this transformation was performed during the conversion
from the Standard to the LLVM dialect. This does not scale well to multiple
dialects targeting the LLVM dialect as all of them would have to be aware of
this limitation and perform the preparatory transformation. Instead, do it as a
separate pass and run it immediately before the translation.

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

As suggested as post-commit comment in D75845.

Patch by Michael Roe.

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

For normal loads, fully eliminate the load. For the TFE case, adjust
the dmask value in the instruction so the selector doesn't need to
handle it. For the TFE special case, I guess it would be possible to
replace the loaded data register with undef, but as-is this will start
treating it as a well defined value.

Trim elements that won't be written. The equivalent still needs to be
done for writes. Also start widening 3 elements to 4
elements. Selection will get the count from the dmask.

Pack the address registers in the legalizer. Avoid introducing a huge
family of new intermediate operations by filling dead operands with
noreg.

Added parsing/sema/serialization support for detach clause.

This excludes some builtins that take argument types not yet handled
by the `-fdeclare-opencl-builtins` machinery, and also excludes
builtins that are already defined in `Builtins.def`.

Just adding trailing newlines that "...: 1" doesn't match "...: 10".

MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain
cl::opt with static storage.
These headers are meant to be incuded by tools to make it easier to parametrize
codegen/mc.

However, these headers are also included in at least two libraries: lldCommon
and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference
to the options, and lldCommon holds another reference. Linking the two in a
single executable, as zig does[0], results in a double registration.

This patch explores an other approach: the .inc files are moved to regular
files, and the registration happens on-demand through static declaration of
options in the constructor of a static object.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5

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

Sizeless types can't be used with "new", so it doesn't make sense
to use them with "delete" either.  The SVE ACLE therefore doesn't
allow that.

This is slightly stronger than for normal incomplete types, since:

  struct S;
  void f(S *s) { delete s; }

is (by necessity) just a default-on warning rather than an error.

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

Summary:
Currently, ValueRange is very hard to extend with new kind of constraints.
For instance, it forcibly encapsulates relations between arguments and the
return value (ComparesToArgument) besides handling the regular value
ranges (OutOfRange, WithinRange).
ValueRange in this form is not suitable to add new constraints on
arguments like "not-null".

This refactor introduces a new base class ValueConstraint with an
abstract apply function. Descendants must override this. There are 2
descendants: RangeConstraint and ComparisonConstraint. In the following
patches I am planning to add the NotNullConstraint, and additional
virtual functions like `negate()` and `warning()`.

Reviewers: NoQ, Szelethus, balazske, gamesh411, baloghadamsoftware, steakhal

Subscribers: whisperity, xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, cfe-commits

Tags: #clang

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

new-expressions for a type T require sizeof(T) to be computable,
so the SVE ACLE does not allow them for sizeless types.  At the moment:

  auto f() { return new __SVInt8_t; }

creates a call to operator new with a zero size:

  %call = call noalias nonnull i8* @_Znwm(i64 0)

This patch reports an appropriate error instead.

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

The error_stream and result parameter were inconsistently checked for
being null, so we might as well make them references instead of crashing
in case someone passes a nullptr and hits one of the code paths that are
currently not doing a nullptr check on those parameters. Also change
output_stream for consistency.

This flag is used by avr-gcc (starting with v10) to set the width of the
double type. The double type is by default interpreted as a 32-bit
floating point number in avr-gcc instead of a 64-bit floating point
number as is common on other architectures. Starting with GCC 10, a new
option has been added to control this behavior:
https://gcc.gnu.org/wiki/avr-gcc#Deviations_from_the_Standard

This commit keeps the default double at 32 bits but adds support for the
-mdouble flag (-mdouble=32 and -mdouble=64) to control this behavior.

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

I believe the actual opcode does not matter because the AVR architecture
is a Harvard architecture that does not support writing to program
memory. Therefore, debuggers and emulators provide hardware breakpoints.
But for some reason, this opcode must be defined or else LLDB will crash
with an assertion error.

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

This was part of D60582 but can be committed separately.

With -fstack-protector-strong we check if a non-array variable has its address
taken in a way that could cause a potential out-of-bounds access. However what
we don't catch is when the address is directly used to create an out-of-bounds
memory access.

Fix this by examining the offsets of GEPs that are ultimately derived from
allocas and checking if the resulting address is out-of-bounds, and by checking
that any memory operations using such addresses are not over-large.

Fixes PR43478.

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

In the current SVE ACLE spec, the usual rules for throwing and
catching incomplete types also apply to sizeless types.  However,
throwing pointers to sizeless types should not pose any real difficulty,
so as an extension, the clang implementation allows that.

This patch enforces these rules for catch statements.

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

A memref argument is converted into a pointer-to-struct argument
of type `{T*, T*, i64, i64[N], i64[N]}*` in the wrapper function,
where T is the converted element type and N is the memref rank.

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

Summary:
The same rules for throwing and catching incomplete types also apply
to sizeless types.  This patch enforces that for throw statements.
It also make sure that we use "sizeless type" rather "incomplete type"
in the associated message.  (Both are correct, but "sizeless type" is
more specific and hopefully more user-friendly.)

The SVE ACLE simply extends the rule for incomplete types to
sizeless types.  However, throwing pointers to sizeless types
should not pose any real difficulty, so as an extension,
the clang implementation allows that.

Reviewers: sdesmalen, efriedma, rovka, rjmccall

Subscribers: tschuett, rkruppe, psnobl, cfe-commits

Tags: #clang

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

This was previously crashing due to a missing nullptr check (see
e2d8aa6b ). This just adds a test that should
make sure this doesn't crash in case a user ends up in this strange setup.

In the current SVE ACLE spec, the usual rules for throwing and
catching incomplete types also apply to sizeless types.  However,
throwing pointers to sizeless types should not pose any real difficulty,
so as an extension, the clang implementation allows that.

This patch enforces these rules for explicit exception specs.

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

This patch completes a trio of changes related to arrays of
sizeless types.  It rejects various forms of arithmetic on
pointers to sizeless types, in the same way as for other
incomplete types.

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

clang currently accepts:

  __SVInt8_t &foo1(__SVInt8_t *x) { return *x; }
  __SVInt8_t &foo2(__SVInt8_t *x) { return x[1]; }

The first function is valid ACLE code and generates correct LLVM IR
(and assembly code).  But the second function is invalid for the
same reason that arrays of sizeless types are.  Trying to code-generate
the function leads to:

  llvm/include/llvm/Support/TypeSize.h:126: uint64_t llvm::TypeSize::getFixedSize() const: Assertion `!IsScalable && "Request for a fixed size on a s
calable object"' failed.

Another problem is that:

  template<typename T>
  constexpr __SIZE_TYPE__ f(T *x) { return &x[1] - x; }
  typedef int arr1[f((int *)0) - 1];
  typedef int arr2[f((__SVInt8_t *)0) - 1];

produces:

  a.cpp:2:48: warning: subtraction of pointers to type '__SVInt8_t' of zero size has undefined behavior [-Wpointer-arith]
  constexpr __SIZE_TYPE__ f(T *x) { return &x[1] - x; }
					   ~~~~~ ^ ~
  a.cpp:4:18: note: in instantiation of function template specialization 'f<__SVInt8_t>' requested here
  typedef int arr2[f((__SVInt8_t *)0) - 1];

This patch reports an appropriate diagnostic instead.

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

This patch makes `Relocation::Addend` to be `ELFYAML::YAMLIntUInt` and not `int64_t`.

`ELFYAML::YAMLIntUInt` it is a new type and it has the following benefits/features:

1) For an 64-bit object any hex/decimal addends
   in the range [INT64_MIN, UINT64_MAX] is accepted.
2) For an 32-bit object any hex/decimal addends
   in range [INT32_MIN, UINT32_MAX] is accepted.
3) Negative hex numbers like -0xffffffff are not accepted.
4) It is printed as decimal. I.e. obj2yaml will print
   something like "Addend: 125", this matches the current behavior.

This fixes all FIXMEs in `relocation-addend.yaml`.

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

Summary:
Adds the constraints described below to ensure that we
can tie variables of SVE ACLE types to operands in inline-asm:
 - y: SVE registers Z0-Z7
 - Upl: One of the low eight SVE predicate registers (P0-P7)
 - Upa: Full range of SVE predicate registers (P0-P15)

Reviewers: sdesmalen, huntergr, rovka, cameron.mcinally, efriedma, rengolin

Reviewed By: efriedma

Subscribers: miyuki, tschuett, rkruppe, psnobl, cfe-commits

Tags: #clang

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

Rename NetBSD-specific Host.cpp to HostNetBSD.cpp to avoid basename
conflict with common/Host.cpp.

Summary:
Move them into MCTargetDesc to follow other architectures (a263aa25).

Reviewed By: simoll

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

This updates the existent test because it lacks coverage.

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

Summary: Matching %x makes the test fail.

Subscribers: cfe-commits

Tags: #clang

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

This test uses a precompiled object and duplicates
the functionality of a modern elf-no-symtab.yaml test that
uses yaml2obj for producing inputs.

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

This is a follow-up for D75608.
The `Offset` property is unused and can be removed to reduce tests.

This patch does nothing with `reloc-types-elf-i386.test` which has a different
structure and kind of tests the `Offset`. I think we might want to split it probably.

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