Title: [RISCV] Add missing part of instruction vmsge {u}. VX Review By: craig.topper  Differential Revision : https://reviews.llvm.org/D100115

Title: [RISCV] Add missing part of instruction vmsge {u}. VX Review By: craig.topper  Differential Revision : https://reviews.llvm.org/D100115

Title: [RISCV] Add missing part of instruction vmsge {u}. VX Review By: craig.topper  Differential Revision : https://reviews.llvm.org/D100115

This patch collects operations that have users in a for loop and uses
them  when loop invariant operations are detected and hoisted.

Reviewed By: bondhugula, vinayaka-polymage

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

This fixes the resolution of Rec10.Zero in ListSlices.td.

As part of this, correct the definition of complete for ListInit such that
it's complete iff all the elements in the list are complete rather than
always being complete regardless of the elements. This is the reason
Rec10.TwoFive from ListSlices.td previously resolved despite being
incomplete like Rec10.Zero was

Depends on D100247

Reviewed By: Paul-C-Anagnostopoulos

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

PATH usage on Windows is case-insensitive. There could be situations
when toolchain path can't be obtained from PATH because of
case-sensitivity of the findVCToolChainViaEnvironment.

Reviewed By: rnk

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

Handles lowering conv2d to linalg's convolution operator. This implementation
only supports floating point values but handles all strides, dilations, and
padding values.

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

This fixes a subtle issue where:

  svprf(pg, ptr, SV_ALL /*is sv_pattern instead of sv_prfop*/)

would be quietly accepted. With this change, the function declaration
guards that the third parameter is a `enum sv_prfop`. Previously `svprf`
would map directly to `__builtin_sve_svprfb`, which accepts the enum
operand as a signed integer and only checks that the incoming range is
valid, meaning that SV_ALL would be discarded as being outside the valid
immediate range, but would have allowed SV_VL1 without issuing a warning
(C) or error (C++).

Reviewed By: c-rhodes

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

Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

I recently ran into issues with aggregates and inheritance, I'm using
it for creating a type-safe library where most of the types are build
over "tagged" std::array. After bit of cleaning and enabling -Wall
-Wextra -pedantic I noticed clang only in my pipeline gives me warning.
After a bit of focusing on it I found it's not helpful, and contemplate
disabling the warning all together. After a discussion with other
library authors I found it's bothering more people and decided to fix
it.

Removes this warning:

template<typename T, int N> struct StdArray {
    T contents[N];
  };

template<typename T, int N> struct AggregateAndEmpty : StdArray<T,N> { };

AggregateAndEmpty<int, 3> p = {1, 2, 3}; // <-- warning here about omitted braces

Per the SPIR-V spec "2.16.2. Validation Rules for Shader Capabilities":

  Composite objects in the StorageBuffer, PhysicalStorageBuffer,
  Uniform, and PushConstant Storage Classes must be explicitly
  laid out.

For other cases we don't need to attach the struct offsets.

Reviewed By: hanchung

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

- Add support for HLASM style integers. These are the decimal integers [0-9].
- HLASM does not support the additional prefixed integers like, `0b`, `0x`, octal integers and Masm style integers.
- To achieve this, a field `LexHLASMStyleIntegers` (similar to the `LexMasmStyleIntegers` field) is introduced in `MCAsmLexer.h` as well as a corresponding setter.

Note: This field could also go into MCAsmInfo.h. I used the previous precedent set by the `LexMasmIntegers` field.

Depends on https://reviews.llvm.org/D99286

Reviewed By: epastor

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

The previous implementation was insufficient for checking statement
attribute mutual exclusion because attributed statements do not collect
their attributes one-at-a-time in the same way that declarations do. So
the design that was attempting to check for mutual exclusion as each
attribute was processed would not ever catch a mutual exclusion in a
statement. This was missed due to insufficient test coverage, which has
now been added for the [[likely]] and [[unlikely]] attributes.

The new approach is to check all of attributes that are to be applied
to the attributed statement in a group. This required generating
another DiagnoseMutualExclusions() function into AttrParsedAttrImpl.inc.

Originally done for rdar://problem/57155465.

rdar://76602859

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

This should unbreak incremental builds after https://github.com/llvm/llvm-project/commit/8ca366935b055283b571ba0893f53a7a18ac59bb

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

Overflows are never fun.
In most cases (in most of the code), they are rare,
because usually you e.g. don't have as many elements.

However, it's exceptionally easy to fall into this pitfail
in code that deals with images, because, assuming 4-channel 32-bit FP data,
you need *just* ~269 megapixel image to case an overflow
when computing at least the total byte count.

In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs:
* https://github.com/darktable-org/darktable/pull/7740
* https://github.com/darktable-org/darktable/pull/7419
* https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c
* https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28
* https://github.com/darktable-org/darktable/pull/670
* https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583

and yet they clearly keep resurfacing still.

It would be immensely helpful to have a diagnostic for those patterns,
which is what this change proposes.

Currently, i only diagnose the most obvious case, where multiplication
is directly widened with no other expressions inbetween,
(i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`)
however that might be worth relaxing later.

Reviewed By: aaron.ballman

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

It broke when FPBits was converted to a union.

Currently, for any extern variable, if it doesn't have
section attribution, it will be put into a default ".extern"
btf DataSec. The initial design is to put every extern
variable in a DataSec so libbpf can use it.

But later on, libbpf actually requires extern variables
to put into special sections, e.g., ".kconfig", ".ksyms", etc.
so they can be used properly based on section name.

Andrii mentioned since ".extern" variables are
not actually used, it makes sense to remove it from
the compiler so libbpf does not need to deal with it,
esp. for static linking. The BTF for these extern variables
is still generated.

With this patch, I tested kernel selftests/bpf and all tests
passed. Indeed, removing ".extern" DataSec seems having no
impact.

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

SinkPtr was not correctly marked as volatile, causing the malloc to get
optimized out.  This was causing 20-minute timeouts for the test and no
OOM.

Fixes https://llvm.org/PR49906.

I've run into some cases where a large fraction of compile-time is
spent invalidating SCEV. One of the causes is forgetLoop(), which
walks all values that are def-use reachable from the loop header
phis. When invalidating a topmost loop, that might be close to all
values in a function. Additionally, it's fairly common for there to
not actually be anything to invalidate, but we'll still be performing
this walk again and again.

My first thought was that we don't need to continue walking the uses
if the current value doesn't have a SCEV expression. However, this
isn't quite right, because SCEV construction can skip over values
(e.g. for a chain of adds, we might only create a SCEV expression
for the final value).

What this patch does instead is to only walk the (full) def-use chain
of loop phis that have a SCEV expression. If there's no expression
for a phi, then we also don't have any dependent expressions to
invalidate.

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

Adds the __clang_literal_encoding__ and __clang_wide_literal_encoding__
predefined macros to expose the encoding used for string literals to
the preprocessor.

[RISCV] Rename RISCVISD::GREVI(W)/GORCI(W) to RISCVISD::GREV(W)/GORC(W). Don't require second operand to be a constant.

Prep work for adding intrinsics for these instructions in the
future.

G_CTPOP can be directly selected to CNT in these cases.

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

[flang][OpenMP] Modify semantic check for nesting of `ordered` regions to include `close` nesting check.

Reviewed By: kiranchandramohan

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

We were not instantiating procedure pointer components.  If the instantiation
contained errors, we were not reporting them.  This resulted in internal errors
in later processing.

I fixed this by adding code in .../lib/Semantics/type.cpp in
InstantiateComponent() to handle a component with ProcEntityDetails.  I also
added several tests for various good and bad instantiations of procedure
pointer components.

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

We need to unpoison parameters before calling into MSan-instrumented
user-defined mutators.

Addresses https://github.com/google/oss-fuzz/issues/4605.

Reviewed By: metzman

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

Address Shafik Yaghmour's post commit code review feedback.

Given this is checking attributes, there are a bunch of valid ways that O2 can infer attributes that CSE will not.

https://lists.llvm.org/pipermail/openmp-dev/2021-March/003940.html reports
test failure in `openmp-offload-gpu.c`. The failure is, when using `-S` in the
clang driver, it still reports bitcode library doesn't exist. However, it is not
exposed in my local run and Phabiractor test. The reason it escaped from Phabricator
test is, the test machine doesn't have CUDA, so `LibDeviceFile` is empty. In this
case, the check of `OPT_S` will be hit, and we get "expected" result. However, if
the test machine has CUDA, `LibDeviceFile` will not be empty, then the check will
not be done, and it just proceeds, trying to add the bitcode library. The reason
it escaped from my local run is, I didn't build ALL targets, so this case was
marked UNSUPPORTED.

Reviewed By: kkwli0

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

Introduce new m_current_process and m_continue_process variables that
keep the pointers to currently selected process.  At this moment, this
is equivalent to m_debugged_process_up but it lays foundations for
the future multiprocess support.

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

Caught by ubsan (__ubsan_handle_load_invalid_value_abort) when running
the unit tests.

This allows one to cross-compile the header/object for a model in a
setup where the compiler is built on a system that cannot host the AOT
compiler. For example, if arm-hostable clang is desired, while the AOT
Tensorflow compiler can cross-compile to arm, it can't currently run on
arm.

The only alternative in that scenario would be to cross-compile clang
itself, but that gets complicated when trying to run tests after that.

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

This reverts commits:
* 8914902b
* 35a745d8
* 682d1dfe

[X86][SSE] combineSetCCMOVMSK - allow comparison with upper (known zero) bits in CMP(MOVMSK(PACKSS())) -> CMP(MOVMSK()) fold

We already allow the comparison of the upper bits of 'IsAllOf' (allbits) patterns, but we can safely compare the known zero bits for 'IsAnyOf' (zerobits) patterns as well.

This fixes an issues where we are comparing a type wide than the number of vector elements, which avoids a regression mentioned in rGbaadbe04bf75.