Reviewed By: aartbik, anlunx

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

Fix issues found by clang-tidy in clang-tidy source directory.

In particular, high LMULs, constant offsets within high LMUL, and types which require splitting.  Note that most of these are way off with current lowering.

Try to use VALIGN as a cross-lane version of VSHLDQ/VSRLDQ

This patch makes structural-hash-detailed.ll look at diffs rather than
specific values to make the test more robust against the underlying
hashing implementation while still testing that the hash value is
deterministic across multiple runs.

Reviewed By: aeubanks

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

This reverts commit 01483019.
and ce12d656.

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

In particular, at mixed LMULS, high LMULS, and types which require splitting.

warning was updated in 92023b15

If there is no output filename we should not assert when writing output
for -MJ.

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

Just a small follow-up for https://reviews.llvm.org/D159122

Only pass it +unaligned-scalar-mem/-unaligned-scalar-mem if the
user has passed one of the alignment options.

This allows us to add unaligned-scalar-mem as a feature on CPUs
that support it.

Reviewed By: wangpc

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

For function multi-versioning using the target or target_clones
function attributes, currently we incorrectly set comdat for internal
linkage resolvers. This is problematic for ELF linkers
as GRP_COMDAT deduplication will kick in even with STB_LOCAL signature
(https://groups.google.com/g/generic-abi/c/2X6mR-s2zoc
"GRP_COMDAT group with STB_LOCAL signature").

In short, two `__attribute((target_clones(...))) static void foo()`
in two translation units will be deduplicated. Fix this.

Fix #65114

Reviewed By: erichkeane

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

The motivation for this patch is that many code bases use exception handling. As GPUs are not expected to support exception handling in the near future, we can experiment with compiling the code for GPU targets anyway. This will
allow us to run the code, as long as no exception is thrown.

The overall idea is very simple:
- If a throw expression is compiled to AMDGCN or NVPTX, it is replaced with a trap during code generation.
- If a try/catch statement is compiled to AMDGCN or NVPTX, we generate code for the try statement as if it were a basic block.

With this patch, the compilation of the following example
```
int gaussian_sum(int a,int b){
	if ((a + b) % 2 == 0) {throw -1;};
	return (a+b) * ((a+b)/2);
}

int main(void) {
	int gauss = 0;
	#pragma omp target map(from:gauss)
	{
		try {
			gauss = gaussian_sum(1,100);
		}
		catch (int e){
			gauss = e;
		}
	}
	std::cout << "GaussianSum(1,100)="<<gauss<<std::endl;
        #pragma omp target map(from:gauss)
        {
                try {
                     	gauss = gaussian_sum(1,101);
                }
                catch (int e){
                        gauss = e;
                }
        }
	std::cout << "GaussianSum(1,101)="<<gauss<<std::endl;
	return (gauss > 1) ? 0 : 1;
}
```
with offloading to `gfx906` results in
```
./bin/target_try_minimal_fail
GaussianSum(1,100)=5050
AMDGPU fatal error 1: Received error in queue 0x155555506000: HSA_STATUS_ERROR_EXCEPTION: An HSAIL operation resulted in a hardware exception.
zsh: abort (core dumped)
```

Reviewed By: jdoerfert

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

An execute-only target disallows data access to code sections.
-fsanitize=function and -fsanitize=kcfi instrument indirect function
calls to load a type hash before the function label. This results in a
non-execute access to the code section and a runtime error.

To solve the issue, -fsanitize=function should not be included in any
check group (e.g. undefined) on an execute-only target. If a user passes
-fsanitize=undefined, there is no error and no warning. However, if the
user explicitly passes -fsanitize=function or -fsanitize=kcfi on an
execute-only target, an error will be emitted.

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

Reviewed By: MaskRay, probinson, simon_tatham

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

This makes it much easier to understand which vector length is being considered when the same set of nodes are evaluated at multiple vector lengths.

Reviewed By: arsenm, #amdgpu

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

Expand-Atomic pass emits the CAS loop for FP operations
which limits the optimizations offered by atomic optimizer.

Moving atomic optimizer before expand-atomics allows
better codegen.

Reviewed By: arsenm, #amdgpu

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

Reduction and Scan are implemented using `Iterative`
and `DPP` strategy for `float` type.

Reviewed By: arsenm, #amdgpu

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

This fixes a build error introduced by https://reviews.llvm.org/D153587

Also picks up a few improvements (Some of the fcmp.ll
test names imply they aren't quite testing what was intended.
Checking the sign bit can't be performed with a compare to a 0).

Much of the logic in here is the same as the class detection
logic of fcmpToClassTest. We could unify more with a weaker
version of fcmpToClassTest which returns implied classes rather
than exact class-like compares. Also could unify more with detection
of possible classes in non-splat vectors.

One problem here is we now only perform folds that used
to always work now require a context instruction. This is
because fcmpToClassTest requires the parent function.
Either fcmpToClassTest could tolerate a missing context
function, or we could require passing in one to simplifyFCmpInst.
Without this it's possible to hit the !isNan assert (which feels like
an unnecessary assert). In any case, these cases don't appear in
any tests.

https://reviews.llvm.org/D151887

This was working around the lack of operator| on FastMathFlags. We
have that now which revealed the bug.

Fixes https://llvm.org/PR65011

Reviewed By: #libc, ldionne

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

for 92023b15

Extend `GlobPattern` to support brace expansions, e.g., `foo.{c,cpp}` as discussed in https://reviews.llvm.org/D152762#4425203.

The high level change was to turn `Tokens` into a list that gets larger when we see a new brace expansion term. Then in `GlobPattern::match()` we must check against each token group.

This is a breaking change since `{` will no longer match a literal without escaping. However, `\{` will match the literal `{` before and after this change. Also, from a brief survey of LLVM, it seems that `GlobPattern` is mostly used for symbol and path matching, which likely won't need `{` in their patterns.

See https://github.com/devongovett/glob-match#syntax for a nice glob reference.

Reviewed By: MaskRay

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

This patch adds two new macros to setjmp (STORE, STORE_FP) and two new
macros to longjmp (LOAD, LOAD_FP) that takes a register and a buff, then
select the correct asm instruction for rv32 and rv64.

Reviewed By: sivachandra

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

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

* Check and emit out differences in rpath inputs
* Prevent rpaths from being overwritten
* Capture file path for tbd-v5

Also improves undef handling

https://reviews.llvm.org/D159006

This patch changes the instruction in set_thread_ptr from ld to mv,
as rv32 doesn't have the ld instruction, and mv is supported by both
rv32 and rv64.

Reviewed By: sivachandra

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

Reviewed By: simon-camp

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

/data/home/jiefu/llvm-project/flang/lib/Optimizer/CodeGen/CodeGen.cpp:2905:20: error: unused function 'attributeTypeIsCompatible' [-Werror,-Wunused-function]
static inline bool attributeTypeIsCompatible(mlir::MLIRContext *ctx,
                   ^
1 error generated.

This patch changes a test case that tests for overflow when time_t is
32-bit long, however, it was checking size_t instead of time_t.

This in on par with other testcases that correctly check the size of
time_t (asctime_test.cpp, gmtime_r_test.cpp and gmtime_test.cpp).

Reviewed By: sivachandra

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

From the discussion in https://reviews.llvm.org/D158853, moving the truncate
into the splat helps more splatted scalar operands get selected on RISC-V, and
also avoids the need for splat_vector_parts on RV32.

Reviewed By: RKSimon

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