Mostly mechanical changes to add the missing field.

…ertps(freeze(x),freeze(y),i) (llvm#160852)

…oisonForTargetNode - add X86ISD::VPERMILPV handling (llvm#160849)

X86ISD::VPERMILPV shuffles can't create undef/poison itself, allowing us to fold freeze(vpermilps(x,y)) -> vpermilps(freeze(x),freeze(y))

…rical

That provides vastly better plots.

Enable the generation of no-loop kernels for Fortran OpenMP code. target
teams distribute parallel do pragmas can be promoted to no-loop kernels
if the user adds the -fopenmp-assume-teams-oversubscription and
-fopenmp-assume-threads-oversubscription flags.

If the OpenMP kernel contains reduction or num_teams clauses, it is not
promoted to no-loop mode.

The global OpenMP device RTL oversubscription flags no longer force
no-loop code generation for Fortran.

…nal (llvm#160740)

Currently `memcpy` and `memset` intrinsics map through to the library
implementations if ASan has been inited, whereas `memmove` always calls
`internal_memmove`.

This patch changes `memmove` to use the library implementation if ASan
has been inited.

Clang on Darwin enables non-POSIX extensions by default.
This causes some macros to leak, such as HUGE from <math.h>, which
causes some conflicts with Flang symbols (but not with Flang-RT, for
now).

It also causes some Flang-RT extensions to be disabled, such as FDATE,
that checks for _POSIX_C_SOURCE. Setting _POSIX_C_SOURCE avoids these
issues. This is already being done in Flang, but it was not ported to
Flang-RT.

This also fixes check-flang-rt on Darwin, as NoArgv.FdateNotSupported
is broken since the flang runtime was moved to flang-rt.

Fixes llvm#82036

Summary:
This unifies the interface to just be a bunch of `load` and `store`
functions that optionally accept a mask / indices for gathers and
scatters with masks.

I had to rename this from `load` and `store` because it conflicts with
the other version in `op_generic`. I might just work around that with a
trait instead.

…vm#160840)

## Details:
- Added missing compound assignment operators `|=`, `&=`, `^=` to
`mlir-tblgen`
- Replaced the arithmetic operators with added assignment operators for
`BitEnum` in the transformations
- Updated related documentation


## Tickets:
- Closes llvm#158098

## Problem

`RemoveDeadValues` can legally drop dead function arguments on private
`func.func` callees. But call-sites to such functions aren't fixed if
the call operation keeps its call arguments in a **segmented operand
group** (i.ie, uses `AttrSizedOperandSegments`), unless the call op
implements `getArgOperandsMutable` and the RDV pass actually uses it.

## Fix
When RDV decides to drop callee function args, it should, for each
call-site that implements `CallOpInterface`, **shrink the call's
argument segment** via `getArgOperandsMutable()` using the same dead-arg
indices. This keeps both the flat operand list and the
`operand_segment_sizes` attribute in sync (that's what
`MutableOperandRange` does when bound to the segment).

## Note
This change is a no-op for:
* call ops without segment operands (they still get their flat operands
erased via the generic path)
* call ops whose calle args weren't dropped (public, external,
non-`func-func`, unresolved symbol, etc)
* `llvm.call`/`llvm.invoke` (RDV doesn't drop `llvm.func` args

---------

Co-authored-by: Mehdi Amini <[email protected]>

…160603)

It was brought up on a previous review that the CIRGenOpenACCRecipe.h
file was getting too large. I noticed that the 'dependent on template
argument' parts were actually quite small, so I extract a base class in
this patch that allows me to implement it in the .cpp file, plus
minimize the amount of code that needs instantiating.

…n arguments (llvm#160755)

In llvm#153973 I added the correctly handling of block arguments,
unfortunately this was gated on operation that also have results. This
wasn't intentional and this excluded operations like function from being
correctly processed.

)

This heuristic was originally added in 40c4aa with the stated purpose of
avoiding global split on live long ranges created by MachineLICM
hoisting trivially rematerializable instructions. In the meantime,
various backends have introduced non-trivial rematerialization cases,
MachineLICM gained an explicitly triviality check, and we've reworked
our APIs to match naming wise. Let's move this heuristic back to truely
trivial remat only.

This is a functional change, though somewhat hard to hit. This change
will cause non-trivially rematerializable instructions to be globally
split more often. This is likely a good thing since non-trivial remat
may not be legal at all possible points in the live interval, but may
cost slightly more compile time.

I don't have a motivating example; I found it when reviewing the callers
of isRemMaterializable(MI).

…lvm#160761)

We didn't have trace logging for two cases in this routine which makes
it sometimes hard to tell what is going on. In addition to debug trace
statements, add comments to explain the logic behind the early exits
which don't mark the virtual register live. Suggestions on how to word
these more precisely very welcome; I'm not clear I understand all the
intrinicies of this code myself.

…lvm#160765)

We should always be able to find the VNInfo in the original live
interval which corresponds to the subset we're trying to spill, and the
only cases where we have a VNInfo without a definition instruction are
if the vni is unused, or corresponds to a phi. Adjust the code structure
to explicitly check for PHIDef, and assert the stronger conditions.

Currently, RVV/SVE intrinsics are cached, but the corresponding type
construction is not. As a result, `ASTContext::getScalableVectorType`
can become a performance hotspot, since every query must run through a
long sequence of type checks and macro expansions.

FreeBSD libc has a lot of symbols that are ifuncs, which makes TLI
checker believe they are not available. This change makes the tool
consider symbols with the STT_GNU_IFUNC type.

Uses the existing format of the LiveRange printer, and just factors it
out so that you can do vni->dump() when debugging, or log a vni in a
debug print statement.

…g the update script. (llvm#161190)

… are not pointers (llvm#160511)

https://github.com/llvm/llvm-project/blob/main/clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp#L675-L678
mistakenly assumes that target expressions are of pointer type.
`CheckOverlap` has multiple call sites, most of which do not verify this
assumption. Therefore, the simplest solution is to verify it just before
that point.

Make sure that the ALLOCATE directive adds its source span to the
current scope, and that the scope checks compare scoping units, not the
specific scopes.

…aCapture

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

Co-authored-by: Congcong Cai <[email protected]>
Co-authored-by: Baranov Victor <[email protected]>

…tureCheck.cpp

Co-authored-by: Baranov Victor <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

on-behalf-of: @amd <[email protected]>

Co-authored-by: Victor Chernyakin <[email protected]>

on-behalf-of: @amd <[email protected]>