When a dummy argument is a procedure pointer without INTENT(IN),
any actual argument must also be a procedure pointer, whether the
dummy procedure pointer's interface is explicit or not.

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

Also invalidate block and loop dispositions during non-trivial
unswitching.

Fixes #58564.

We implemented 19.3.4p1 literally in name resolution:

  A component name has the scope of its derived-type definition. Outside the type definition,
  it may also appear within a designator of a component of a structure of that type or as a
  component keyword in a structure constructor for that type.

and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.

It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols.  Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.

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

Make a requested change to the wording of a fatal I/O error
message.

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

This was previously attempted in 2016 by colinl's D18770, but LLD tests
were missed, which caused the change to be reverted.

Setting --print-imm-hex by default brings llvm-objdump's behavior closer
in line with objdump, and it makes it easier to read addresses and
alignment from the disassembly. It may make non-address immediates
harder to interpret, but it still seems the better default, barring more
context-sensitive base selection logic.

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

This prepares for an upcoming change to make --print-imm-hex the default
behavior of llvm-objdump. A few newly-added tests were missed the first
time around.

See D136972 for details.

This patch fixes:

  lld/MachO/SyntheticSections.cpp: In member function ‘virtual void
  lld::macho::ChainedFixupsSection::writeTo(uint8_t*) const’:

Previous attempt to work around a bogus error from MSVC 14 on
code from a recent patch failed, so add an #ifdef and disable
the feature for MSVC builds to get the build bot back up.

This patch fixes:

  lld/MachO/OutputSegment.cpp:50:43: warning: enumerated and
  non-enumerated type in conditional expression [-Wextra]

This reverts commit 95eaefd0.

I accidentally committed a patch to add a redundant typename.

The current test in printf-5.c appears to try to emit a volatile memcpy for the
format string, but it doesn't because the volatile qualifier is implicitly
casted away. Using a string literal instead preserves the volatile qualifier.

This is a follow-up to D137031 and is a prerequisite for D136822, which elides
memcpys in more instances and would otherwise break this test.

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

This patch fixes:

  llvm/lib/Target/AMDGPU/SIInstrInfo.cpp:7383: warning: enumerated
  mismatch in conditional expression:
  ‘llvm::AMDGPU::UfmtGFX11::UnifiedFormat’ vs
  ‘llvm::AMDGPU::UfmtGFX10::UnifiedFormat’

This patch fixes:

  llvm/lib/Target/Mips/MipsInstrInfo.cpp:71:52: warning: enumerated
  and non-enumerated type in conditional expression [-Wextra]

Recode a recent patch in an attempt to dodge a nonsensical error
from MSVC 14.

This patch fixes:

  llvm/lib/Target/Hexagon/HexagonVectorCombine.cpp:1554:6: warning:
  ‘llvm::Value*
  {anonymous}::HexagonVectorCombine::simplify(llvm::Value*) const’
  defined but not used [-Wunused-function]

This patch fixes:

  llvm/utils/unittest/googletest/include/gtest/gtest.h:1526:11: error:
  comparison of integers of different signs: 'const unsigned long' and
  'const int' [-Werror,-Wsign-compare]

[Re-submit after earlier revert due to a test failure. Commit dce78646
("clang-tblgen build: avoid duplicate inclusion of libLLVMSupport")
is believe to address the root cause of the test failure.]

Follow the pattern used in MLIR for the cl::opt instances.

v2:
- make DebugCounter::isCountingEnabled public so that the
  DebugCounterOwner doesn't have to be a nested class. This simplifies
  later changes

v3:
- remove the indirection via DebugCounterOwner::instance()

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

This patch fixes:

  flang/lib/Evaluate/fold-integer.cpp:613:25: error: lambda capture
  'name' is not used [-Werror,-Wunused-lambda-capture]

MSVC emits a warning on some recently patched code; fix it.

Pointer64Anon was lifted out of the MachO backend and into aarch64.h when that
header was created, but Pointer64Anon is really a MachO-specific "normalized"
relocation value, rather than a generic Edge::Kind. Any uses can be safely
replaced with Pointer64.

(Side note: the role of MachOPointer64Anon is to aid MachO relocation parsing:
For MachOPointer64, the target symbol is specified by the r_symbolnum field in
the relocation. For MachOPointer64Anon the address of the anonymous target is
read from the fixup location.)

The common language extension that allows arbitary expressions
to be used as components in a complex constructor (x,y) -- not both
constant, since that would make it a complex literal constant --
still have to be scalar; it's not an elemental operation like the
CMPLX() intrinsic function is.

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

When the compile-time result value of a reference to an integer-valued intrinsic
function COUNT, ICHAR, IACHAR, INDEX, SCAN, or VERIFY cannot be represented in
the selected result kind, emit a warning.

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

These are the same asserts we have in other query routines; cover this interface too.

These overrides should now match the default WriteShuffle schedules

This also fixes a typo where we were missing load latencies for the memory folded variants

We have similar code to translate a demanded elements mask for a shuffle's operands in multiple places - this patch adds a helper function to VectorUtils and updates a number of locations to use it directly.

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

Enforce remaining semantic restrictions on the arguments to MOVE_ALLOC,
namely that the first two arguments must be allocatable (!) and that
if the source is polymorphic, so must the destination be.

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

This extends the computeKnownBits analysis to support scalable vectors. The critical detail is in deciding how to represent the demanded elements of a vector whose length is unknown at compile time.

For this patch, I adopt the convention that we track one bit which corresponds to all lanes. That is, that bit is implicitly broadcast to all lanes of the scalable vector resulting in all lanes being demanded. This is the same convention we use in getSplatValue in SelectionDAG.

Note that this convention doesn't actually impact much. Most of the code is agnostic to the interpretation of the demanded elements, and the few cases which actually care need case by case handling anyways. In this patch, I just bail out of those cases.

A prior patch (D128159) proposed using a different convention in SDAG. I don't see any strong reason to prefer one scheme over the other, so I propose we go with this one as it's conceptually the simplest. Getting known and demanded bit optimizations unblocked at all is a significant win.

I've locally implemented this scheme in reasonable large parts of ValueTracking.cpp and SelectionDAG equivalents, and have not hit any blockers. If this is approved, I plan to post a series of patches plumbing this through all the relevant parts.

In the discussion on that patch, a preference was expressed for introducing some form of abstraction around the demanded elements. I'll note that I've played with several variations on that idea locally, and have yet to find anything which results in more readable code. If anyone has concrete ideas in this area, I'm happy to explore in follow up patches. I'd strongly prefer to be making API changes in NFC manner with tests in place.

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

znver1/2 uses pipes0/1/3 for most integer ALU and nearly all integer/float shuffles occur on pipes1/2

More cleanup work to hopefully get shuffle kinds costs testing added to the D103695 script sometime soon

Confirmed with the AMD SoG, Agner + instlatx64

Fixes another mismatch between the D103695 script and the znver1 scheduler model

Confirmed with the AMD SoG, Agner + instlatx64

Precommit for D136015
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D137019

This should address the issue found in:
https://lab.llvm.org/buildbot/#/builders/92/builds/34906

This patch addresses https://github.com/llvm/llvm-project/issues/19756

Reviewed By: MyDeveloperDay, HazardyKnusperkeks

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

[test][InstCombine] Add tests for removing memcpy to an alloca that is passed to a readonly nocapture function parameter, in preparation for D136822.

This commit adds tests to Transforms/InstCombine/memcpy-from-global.ll that
test various situations involving memcpy from a constant to an alloca that is
then passed to function parameters with various attributes. The forthcoming
D136822 allows InstCombine to remove these memcpys if they're passed to a
single readonly nocapture parameter.

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

InstCombine can replace memcpy to an alloca with a pointer directly to the
source in certain cases. Unfortunately, it also did so for volatile memcpys.
This patch makes it stop doing that.

This was discovered in D136822.

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

[test][InstCombine] Add a test case for volatile memcpy forwarding in InstCombine, which is currently optimized incorrectly.

D136822 demonstrated that we currently delete volatile memcpys in InstCombine,
which we shouldn't do. This commit adds a test for this. A forthcoming commit
will fix it.

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

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

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

This patch fixes:

  mlir/include/mlir/IR/PatternMatch.h:1209:72: warning: parameter
  ‘values’ set but not used [-Wunused-but-set-parameter]