If a namelist item is an allocatable or pointer and is also part of a common
block, the box should be loaded from the common block ref.

Reviewed By: PeteSteinfeld

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

Reviewed By: arsenm, sameerds

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

This does *not* link with libLLVM, but with static archives instead. Not
super-great, but at least the build works, which is probably better than
failing.

Related to #57551

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

Reviewed By: aartbik

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

To `AsmParser` and also to the assembly format

Reviewed By: rriddle

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

Summary:
This flag was deprecated awhile back but still shows up when using
`clang --help`. This patch just gets rid of it but keeps its interface
for backward compatibility.

- 47afaf2e changed llvm-exegesis cmake rules
- 5b2f838d ported them to bazel, but did so by adding all the `lib/{target}/*.cpp` sources in exegesis to the build rule
- c7bf9d08 removed it, because it breaks users who don't build Mips and fail when building `lib/Mips/*.cpp`. But that in turn breaks those who *do* build the Mips target.

This should hopefully fix it for the final time by using selectively build subdirectories of exegesis target libs using llvm_target_exegesis, which is derived from llvm_targets, and is the list that can vary based on the downstream user.

I verified this builds with and without `Mips` in the `DEFAULT_TARGETS` configure list, and also double checked with `bazel query --output=build @llvm-project//llvm:Exegesis` that `lib/Mips/Target.cpp` is being included if and only if `Mips` is in the target list.

Reviewed By: aeubanks

Differen...

Add OpenMP device runtime build support for the gfx1100, gfx1101,
gfx1102, and gfx1103 targets.

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

This extends the uniform base transform used with scatter/gather to support one-use vector adds-of-splats with a non-zero base. This has the effect of essentially reassociating an add from vector to scalar domain.

The motivation is to improve the lowering of scatter/gather operations fed by complex geps.

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

This patch adds support for if clause to task construct in OpenMP
IRBuilder.

Reviewed By: raghavendhra

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

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

The buildbots do have libxml2 installed.

Fortran is not clear about the semantics of

```
  subroutine subr
    integer n = 1
    block
      data n/2/
    end block
  end subroutine
```

which could be interpreted as having two variables, each
named 'n', or as having one variable 'n' with invalid double
initialization.  Precedents from existing compilers are also
in disagreement.

The most common interpretation, however, agrees with a subtle
reading of the standard: BLOCK constructs scope names that have
local specifications, and a DATA statement is a declaration
construct, not a specification construct.  So this example is
*not* acceptable.

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

By draft of C23 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf),
the description for isless macro under 7.12.17.3 says,

The isless macro determines whether its first argument is less than its second
argument. The value of isless(x,y) is always equal to (x)< (y); however, unlike
(x) < (y), isless(x,y) does not raise the invalid floating-point exception when
x and y are unordered and neither is a signaling NaN.

isless should trap when encountering signaling NaN.

Reviewed By: jcranmer-intel, efriedma

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

Reviewed By: Peiming

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

Recent update added 'tools/llvm-exegesis/lib/Mips/*.cpp' to srcs for Exegesis cc_library. This was not needed, and in fact breaks things. This CL removes that one change.

Reviewed By: aeubanks

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

This patch introduces a logRewardIfNeeded method to reuse regallocscoring.

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

Reviewed By: aartbik

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

The error output is cached so it could be out of order with stdout in
some bots.

Due to CMake mis-configurations, some gtest binaries may be added to the test
list more than once. This patch makes lit avoid such cases and issues a
warning when it happens.

The /Zl flag omits default C runtime library name from obj files.
This patch just adds an equivalent clang driver flag.

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

This reverts commit a212d8da, and follow
on fixes 0cd6763f,
e9ff53d4, and
37c6a25e.

After re-reading the documentation for hash_combine, I don't think this
is the appropriate hash function to use for computing the hash to use as
a stack id in the metadata, since it is not guaranteed to produce stable
values across executions. I have not hit this problem, but plan to
switch to using an MD5 hash. I am hitting an issue with one of the bots
(https://lab.llvm.org/buildbot/#/builders/171/builds/20732)
where the values produced are only the lower 32 bits of the expected
hash values, however, which I assume is related to the implementation of
hash_combine and hash_code.

I believe I fixed all of the other bot failures with the follow on fixes,
which I'll merge into the new version before reapplying.

I suspect the reason for why D134234 was failing sometimes is because
"operator<" for a ValID could compare ValIDs of different kinds but have
the same non-active values and return an incorrect result. This is an
issue if I attempt to store ValIDs of different kinds in an std::map but
we compare different "active" values. For example, if I create an
std::map and store some ValIDs of kind t_GlobalName, then I insert a
ValID of kind t_GlobalID, the current "operator<" will see that one of
the operands is a t_GlobalID and compare it against the UIntVal of other
items in the map, but the other items in the map don't set UIntVal
because they're not t_GlobalIDs, so I compare against a
dummy/uninitialized value.

It seems pretty easy to add mixed ValID kinds into an std::map in
LLParser, so this just asserts that when doing the comparison that both
ValIDs are the same kind.

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

The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.

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

RISCV doesn't actually support a scaled form of indexed load and store. We previously handled this by forming the scaled SDNode, and then doing custom legalization during lowering. This patch instead adds a callback via TLI to prevent formation entirely.

This has two effects:
* First, the GEP gets expanded (and used). Instead of the shift being created with an SDLoc of the memory operation, it has the SDLoc of the GEP instruction. This avoids the scheduler perturbing IR order when there's no reason to.
* Second, we fix what appears to be a bug in index calculation with RV32. The rules for GEPs require index calculation be done in particular bitwidth, and it appears the custom legalization code got this wrong for the case where index type exceeds pointer width. (Or at least, I trust the generic GEP lowering to be correct a lot more.)

The DAGCombiner change to handle VPScatter/VPGather is technically separate, but is required to prevent a regression on those intrinsics.

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

Translate HLSLNumThreadsAttr into function attribute with name "dx.numthreads" and value format as "x,y,z".

Reviewed By: beanz

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

Reviewed By: aartbik

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

This allows downstream uses to use the implementation of the tiling
itself, while performing other transformations that are necessary to
go with it.

Reviewed By: nicolasvasilache

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

Spurious ref edges are ref edges that still exist in the call graph even
though the corresponding IR reference no longer exists. This can cause
issues when deleting a dead function which has a spurious ref edge
pointed at it because currently we expect the dead function's RefSCC to
be trivial.

In the case that the dead function's RefSCC is not trivial, remove all
ref edges from other nodes in the RefSCC to it.

Removing a ref edge can result in splitting RefSCCs. There's actually no
reason to revisit those RefSCCs because currently we only run passes on
SCCs, and we've already added all SCCs in the RefSCC to the worklist.
(as opposed to removing the ref edge in
updateCGAndAnalysisManagerForPass() which can modify the call graph of
SCCs we have not visited yet). We also don't expect that RefSCC
refinement will allow us to glean any more information for optimization
use. Also, doing so would drastically increase the complexity of
LazyCallGraph::removeDeadFunction(), requiring us to return a list of
invalidated RefSCCs and new RefSCCs to add to the worklist.

Fixes #56503

Reviewed By: asbirlea

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

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

This patch adds auto source map deduce count as a target level statistics.
This will help telemetry to track how many debug sessions benefit from this feature.

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

This relands commit 5d4603a0

.
It cludes fixes to GCC test failures and simplification to
the implementation.

Co-authored-by: Mahesh Ravishankar <ravishankarm@google.com>
Co-authored-by: Christopher Bate <cbate@nvidia.com>

All constrained intrinsics return a single value. We can directly
convert it to an EVT instead of going through ComputeValueTypes.

Reviewed by: Changpeng Fang, Matt Arsenault, Brian Sumner

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

Use has_value instead of hasValue to address a deprecation warning from
a212d8da. E.g.:

https://lab.llvm.org/buildbot/#/builders/57/builds/22166/steps/5/logs/stdio

Fix an unused variable warning introduced by a212d8da
due to a bad merge with a recent change. E.g. in
https://lab.llvm.org/buildbot/#/builders/77/builds/22095