This patch adds support for lowering of the `set_exponent` intrinsic
from Fortran to the FIR dialect of MLIR.

This is part of the upstreaming effort from the `fir-dev` branch in [1].

[1] https://github.com/flang-compiler/f18-llvm-project

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eun Jung Park <ejpark@lanl.gov>

NFC. Switch from calculations based on dwords to bits, to be more
flexible.

Reviewed By: rampitec

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

Allow fir.rebox input and output element type to differ for characters
if:
- Any of the character type is dynamic. Fortran allows making pointer
assignments between deferred and constant lengths entities, making this
case useful (if the input length is dynamic and the output length constant,
it is a user requirement that the length matches at runtime. There is no
option to check this at runtime, but it could be added as an option to
fir.rebox codegen later if desired).

- Or, there is a slice in the fir.rebox (the fir.rebox can implement a
substring view, hence the constant output and input lengths).

This is only a verifier constraint change, the fir.rebox codegen is not
impacted and already support those cases.

Add related FIR parsing, error, and codegen tests.

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

This was inadvertedly changed (bad search&replace) when I was removing
the LLDBLOG macros.

When a load extends past the extent of the alloca, SROA will
restrict the slice size to extend to the end of the alloca only.
However, presplitting was asserting that the load size and the
slice size match exactly, which does not hold in this case.
Relax the assertion to only require that the load size is greater
or equal than the slice size.

Change enumaration to enumeration in code handling LLDB help output.

Reviewed By: labath

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

Correct a few spelling errors and typos in the LLDB help output.

Reviewed By: labath

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

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

This removes a restriction wrt. scf.for loops during One-Shot Bufferization. Such IR was previously rejected. It is still rejected by default because the bufferized IR could be slow. But such IR can now be bufferized with `allow-return-allocs`.

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

If BB has a single successor, conditions can be added safely.

New buffer allocations can now be returned/yielded from blocks with `allow-return-allocs`. One-Shot Bufferize deallocates all buffers at the end of the block. If this is not possible (because the buffer escapes the block), this is now done by the existing BufferDeallocation pass.

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

CT_Dependent

When compile following code without -std=c++17, clang will abort by
llvm_unreachable:

class A {
  public:

  static const char X;

};
const char A::X = 0;

template<typename U> void func() noexcept(U::X);

template<class... B, char x>
void foo(void(B...) noexcept(x)) {}

void bar()
{

  foo(func<A>);

}

So, my solution is to let EST_Uninstantiated in
FunctionProtoType::canThrow return CT_Dependent

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

Let exhaustive tests indicate each interval PASSED/FAILED.

Reviewed By: sivachandra

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

* Implement RegionBranchOpInterface: The op has a region, but it is conceptually not entered. The region just describes the semantics of the (monolithic) op.
* Linalg structured ops do not allocate memory.

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

This patch adds lowering for the count intrinsic.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>

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

No need to schedule entry nodes where all instructions are not memory
read/write instructions and their operands are either constants, or
arguments, or phis, or instructions from others blocks, or their users
are phis or from the other blocks.
The resulting vector instructions can be placed at
the beginning of the basic block without scheduling (if operands does
not need to be scheduled) or at the end of the block (if users are
outside of the block).
It may save some compile time and scheduling resources.

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

The original design of custom operands support assumed that most GPUs
have the same or very similar operand names end encodings. This is
no longer the case. As a result the support code becomes over-complicated
and difficult to maintain.

This change implements a different design with the following benefits:

- support of aliases;
- support of operands with overlapped encodings;
- identification of defined but unsupported operands.

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

In 7fb40e15, I changed the availability for bad_optional_access and
friends from macOS 10.14 to 10.13 after conducting an investigation on
old dylibs. It turns out that macOS 10.13 did have bad_optional_access,
however the dylib on iOS didn't match the dylib on macOS, so those
exception classes were only introduced in iOS 12.

Thanks to Aditya Kumar for noticing this.

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

The BinaryEmitter uses opts::AlignText value to align the hot text
section. Also check that the opts::AlignText is at least
equal opts::AlignFunctions for the same reason, as described in D121392.

Vladislav Khmelevsky,
Advanced Software Technology Lab, Huawei

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

It's the role of the C++ ABI library to install its own headers, not libc++.
This fixes an existing issue causing spurious CI failures where both libc++
and libc++abi would try to install <cxxabi.h> & friends in the same location,
leading to failures during the installation step.

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

This is the only test in the ClangScanDeps suite that doesn't convert (double) backslashes to forward slashes.

This test fails on Windows due to path separators

The code for traversing precompiled dependencies is somewhat complicated and contains a dangling iterator bug.

This patch simplifies the code and fixes the bug.

Reviewed By: dexonsmith

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

When pruning header search paths (to reduce the number of modules we need to build explicitly), we can't prune the search paths used in (transitive) dependencies of a module. Otherwise, we could end up with either of the following dependency graphs:

```
X:<hash1> -> Y:<hash2>
X:<hash1> -> Y:<hash3>
```

depending on the search paths of the translation unit we discovered `X` and `Y` from.

This patch fixes that.

Depends on D121295.

Reviewed By: dexonsmith

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

The iterator is not needed after the loop body anymore, meaning we can use more terse range-based for loop.

Depends on D121295.

Reviewed By: dexonsmith

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

To reduce the number of modules we build in explicit builds (which use strict context hash), we prune unused header search paths. This essentially merges parts of the dependency graph.

Determining whether a search path was used to discover a module (through implicit module maps) proved to be somewhat complicated. Initial support landed in D102923, while D113676 attempts to fix some bugs.

However, now that we don't use implicit module maps in explicit builds (since D120465), we don't need to consider such search paths as used anymore. Modules are no longer discovered through the header search mechanism, so we can drop such search paths (provided they are not needed for other reasons).

This patch removes whatever support for detecting such usage we had, since it's buggy and not required anymore.

Depends on D120465.

Reviewed By: dexonsmith

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

Fixes #54171

This is needed for the BufferDeallocation pass.

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

Also clean up/split test cases.

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

This option is added in both `flang-new` (the compiler driver) and
`flang-new -fc1` (the frontend driver). The semantics are consistent
with `clang` and `clang -cc1`.

As Flang does not run any LLVM passes when invoked with `-emit-llvm`
(i.e. `flang-new -S -emit-llvm <file>`), the tests use
`-S`/`-c`/`-emit-obj` instead. These options require an LLVM backend to
be run by the driver to generate the output (this makese `-mllvm`
relevant here).

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

This patch adds lowering for the `adjustl` and `adjustr`
intrinsics.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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



Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>

This patch adds lowering for the `transfer` intrinsic.
The calls are lowered to runtime function calls.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>

This patch adds support for lowering of the `ibset` intrinsic from Fortran
to the FIR dialect of MLIR.

This is part of the upstreaming effort from the `fir-dev` branch in [1].

[1] https://github.com/flang-compiler/f18-llvm-project



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>

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

fneg instruction isel and tests. We do this also in preparation of fused
negatate-multiple-add fp operations.

Reviewed By: kaz7

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

This patch adds initial argmemonly inference, by checking the underlying
objects of locations returned by MemoryLocation.

I think this should cover most cases, except function calls to other
argmemonly functions.

I'm not sure if there's a reason why we don't infer those yet.

Additional argmemonly can improve codegen in some cases. It also makes
it easier to come up with a C reproducer for 7662d168 (already fixed,
but I'm trying to see if C/C++ fuzzing could help to uncover similar
issues.)

Compile-time impact:
NewPM-O3: +0.01%
NewPM-ReleaseThinLTO: +0.03%
NewPM-ReleaseLTO+g: +0.05%

https://llvm-compile-time-tracker.com/compare.php?from=067c035012fc061ad6378458774ac2df117283c6&to=fe209d4aab5b593bd62d18c0876732ddcca1614d&stat=instructions

Reviewed By: nikic

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