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

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

Run mlir-opt with `-debug-only="one-shot-analysis"` for detailed debug output.

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

Fortran standard 7.3.2.3 point 7 mentions that a diassociated
pointer dynamic type is its declared type.
in 9.7.2 note 1, when a NULLIFY statement is applied to a polymorphic pointer,
its dynamic type becomes the same as its declared type.
This patch enforce these standard points by calling the runtime function
`PointerNullifyDerived` with the declared type descriptor.

Reviewed By: jeanPerier

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

This adds the usual complement of APIs for creating and fetching
a non-trivial attribute.

Split out from D135780.

When running with `-debug`, print the IR after bufferizing each op.

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

Follow-up to D135524, to replace two more deprecated C functions
in the OCaml bindings. const_in_bounds_gep now accepts the source
element type as argument, and const_element has been changed into
aggregate_element, which works on a wider range of constants and
returns an option.

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

programUndefinedIfUndefOrPoison used to eagerly propagate the fact that
a value is poison to the users of the value. The problem is that if the
value has a lot of uses (orders of magnitude more than the scanning
limit we use in this function), then we spend the bulk of our time in
eagerly propagating the poison property, which we will mostly never use
later anyway due to the scanning limit.

I have a test case (of ~50k lines of machine generated C++), where this
results in ~60% of 35s compilation time being spent doing just this
eager propagation.

This patch changes programUndefinedIfUndefOrPoison to only propagate to
instructions actually visited, looking back to see if their operands are
poison. This should be equivalent and no functional change is intended,
but we regain virtually all of the 60% compilation time spent in this
function in my test case (i.e.: a 2.5x total compilation speedup).

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

Rather than switching to a new AAQI instance with empty cache when
MayBeCrossIteration is toggled, include the value in the cache key.

The implementation redundantly include the information in both sides
of the pair, but that seems simpler than trying to store it only on
one side.

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

fir.dispatch codegen was done in D136189.

This adds the default attributes (nosync, nofree, nocallback,
willreturn) to the coro.id and coro.subfn.addr intrinsics. This
is needed to avoid optimization regressions in the future.

It's probably possible to use default attributes for most other
coro intrinsics as well, but I only hit these as problematic in
practice.

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

Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.

This change enhances handling errors in the expansion so that users
could get more informative error messages.

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

Place various classes/structs into anonymous namespaces and mark
variables as static. As far as I understand, these are all
implementation details and not intended to be exported -- only a
small number of tsan hooks are supposed to be.

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

This adds the default attributes (nocallback, nosync, nofree,
willreturn) to some X86 intrinsics. This will be needed to avoid
optimization regressions in the future (once we remove the
readonly -> willreturn implication for intrinsics).

Due to the number of intrinsics, this patch focuses just on the
IntrNoMem intrinsics up to the AVX2 section.

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

This addresses post-commit comments and should have been part of D136685.

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

modules

From the discussion in
https://discourse.llvm.org/t/how-should-we-support-dependency-scanner-for-c-20-modules/66027,
we get a consensus that we want to support clang modules and c++ modules
at the same time. This patch documents this intention.

Reviewed By: bruno

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

This permits using the <locale> header with newlib or picolibc when
LIBCXX_ENABLE_WIDE_CHARACTERS=FALSE.

Since D136682 the __support/xlocale headers themselves include the
headers they require, respecting the LIBCXX_ENABLE_WIDE_CHARACTERS
option.

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

This is flicky for buildbots (for example, https://lab.llvm.org/buildbot/#/builders/188/builds/21560)
because of the short timeout. The test coverage is not reduced because
the stdout check is performed in other googtest-* unit tests.

Per wordings in
- https://eel.is/c++draft/over.match#best.general-2.6
- https://eel.is/c++draft/temp.constr.order
- https://eel.is/c++draft/temp.constr#atomic-1

constraints partial ordering should use the unsubstituted template
parameters of the constrained entity, not the instantiated entity.

Fix #56154

Reviewed By: erichkeane, royjacobson, mizvekov

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

follow up https://github.com/llvm/llvm-project/commit/d30e2eefc3cf8dfd2210aefd62f13a6e7c011b43

Reviewed By: mizvekov

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

Summary: We currently optimize the comparison only in SSA, therefore we will miss some optimization opportunities where the input of comparison is lowered from COPY in post-RA.
Ie. ExpandPostRA::LowerCopy is called after PPCInstrInfo::optimizeCompareInstr.
This patch optimizes the comparison in post-RA and only the cases that compare against zero can be handled.
D131374 converts the comparison and its user to a compare against zero with the appropriate predicate on the branch, which creates additional opportunities for this patch.

Reviewed By: shchenz, lkail

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

This brings the aarch64 edges into alignment with the naming scheme for the
x86-64 edges.

Edge behavior is mostly unchanged, but some irrelevant assertions and errors
have been removed.

Print $zero register if operand is zero, otherwise print it normally.

Clang is highly compatible [1] with GCC inline assembly extensions,
allowing the same set of constraints, modifiers and operands as GCC
inline assembly. This patch tries to make it compatible regarding
LoongArch specific operand modifiers.

GCC supports many modifiers [2], but it seems that only x86 and msp430
are documented [3][4]. I don't know if any other modifiers are being
used except the 'z' in Linux [5].

[1]: https://clang.llvm.org/compatibility.html#inline-asm
[2]: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/loongarch/loongarch.cc#L4884-L4911
[3]: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#x86Operandmodifiers
[4]: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#msp430Operandmodifiers
[5]: https://github.com/torvalds/linux/blob/master/arch/loongarch/include/asm/cmpxchg.h#L17

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

If `__builtin_frame_address` or `__builtin_return_address` is invoked with
non-zero argument, show an error message instead of a crash.

Reference: https://reviews.llvm.org/rG83b88441ad951fe99c30402930ef3cd661f2fd2b

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

'J' is defined in GCC [1] but not documented [2] while Linux [3] has
already used it in LoongArch port.

[1]: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/loongarch/constraints.md#L61
[2]: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html
[3]: https://github.com/torvalds/linux/blob/master/arch/loongarch/include/asm/cmpxchg.h#L19

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

A statement function in Fortran may be called, but it may not be the target
of a procedure pointer or passed as an actual argument.

This commit adds support for 32 bit absolute and pc relative relocations in
ELF/i386 objects, along with simple regression tests.

Reviewed By: sgraenitz, lhames

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

Some of the circumstances that require that a procedure have an
explicit interface at a point of call due to a characteristic of
a dummy argument apply to dummy procedures, too.

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

for (I = Start; I < End; I += 1) always terminates so mark
{scf|affine}.for as RecursivelySpeculatable when step is known to be
1.

Reviewed By: chelini

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

This is a vestige of the original MachO-specific edge set and was never used
as a generic aarch64 edge kind.

Disable the test that corresponds to a semantic check that was
disabled to work around an MSVC build problem.

A Fortran program may not specify a particular attribute multiple
times for the same entity in a scope.

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

Currently, InstCombine can elide a memcpy from a constant to a local alloca if
that alloca is passed as a nocapture parameter to a *function* that's readnone
or readonly, but it can't forward the memcpy if the *argument* is marked
readonly nocapture, even though readonly guarantees that the callee won't
mutate the pointee through that pointer. This patch adds support for detecting
and handling such situations, which arise relatively frequently in Rust, a
frontend that liberally emits readonly.

A more general version of this optimization would use alias analysis to check
the call's ModRef info for the pointee, but I was concerned about blowing up
compile time, so for now I'm just checking for one of readnone on the function,
readonly on the function, or readonly on the parameter.

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

As mentioned in https://discourse.llvm.org/t/rfc-extend-ranges-infrastructure-to-better-match-c-20/65377

Lambda objects are not copy assignable, and therefore neither are
iterator types which hold a lambda.  STL code require iterators be
copy assignable.  Users may not use mapped_iterator with a std::deque
for example: https://godbolt.org/z/4Px7odEEd

This blog post [1] explains the problem and solution.  We define a
wrapper class to store callable objects with two specialization.

1. Specialization for non-function types
    - Use a std::optional as storage for non-function callable.
    - Define operator=() implementation(s) which use
      std::optional::emplace() instead of the assignment operator.
2. Specialization for function types
    - Store as a pointer (even if template argument is a function reference).
    - Default construct pointer to nullptr.

This Callable wrapper class is now default constructible (with invalid
state) and copy/move assignable.

With these new properties available on the callable object,
mapped_iterator can define a default constructor as well.

[1] https://www.fluentcpp.com/2019/04/16/an-alternative-design-to-iterators-and-ranges-using-stdoptional/

Reviewed By: kazu

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

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