The smaller class member are more focused and easier to maintain. This
also paves the way for partial header forward compatibility in
https://github.com/llvm/llvm-project/pull/88212



---------

Co-authored-by: Kazu Hirata <kazu@google.com>

Add 'sort' here since it's helpful when container type
changes (for example, https://github.com/llvm/llvm-project/pull/88024
wants to change container type from `unordered_set` to `DenseMap)

@MaskRay points out `std::` doesn't randomize the iteration order of
`unordered_{set,map}`, and the iteration order for single build is
deterministic.

Labels are matched using a regexp of the form '^(pattern):', which
requires the addition of a "suffix" concept to NamelessValue.

Aside from that, the key challenge is that block labels are values, and
we typically capture values including the prefix '%'. However, when
labels appear at the start of a basic block, the prefix '%' is not
included, so we must capture block label values *without* the prefix
'%'.

We don't know ahead of time whether an IR value is a label or not. In
most cases, they are prefixed by the word "label" (their type), but this
isn't the case in phi nodes. We solve this issue by leveraging the
two-phase nature of variable generalization: the first pass finds all
occurences of a variable and determines whether the '%' prefix can be
included or not. The second pass does the actual substitution.

This change also unifies the generalization path for assembly with that
for IR and analysis, in the hope that any future changes avoid diverging
those cases future.

I also considered the alternative of trying to detect the phi node case
using more regular expression special cases but ultimately decided
against that because it seemed more fragile, and perhaps the approach of
keeping a tentative prefix that may later be discarded could also be
eventually applied to some metadata and attribute cases.

Note that an early version of this change was reviewed as
https://reviews.llvm.org/D142452, before version numbers were
introduced. This is a substantially updated version of that change.

This will help in later patches where the checks for operands being
instructions is removed, and might help not remove unnecessary poison lanes.

As a small addition to #91148, this uses copysign to produce the correct
sign for zero when converting frem to div/trunc/mul when we do not know
that the input is positive (and we care about sign bits). The copysign
lets us get the sign of zero correct.

In testing, the only case this produced different results than fmod was:
frem -inf, 4.0 -> nan vs -nan

Fixes: 060df78c

The last use of the function has been removed a while ago. Remove the
unused function.

Add support for generating `st.param` instructions with direct use of
immediates. This eliminates the need for a `mov` instruction prior to
the `st.param` resulting in more concise emitted PTX.

Turns out it was already in Analysis/CFGLoopInfo, so just move it
to IR/AsmPrinter.

```
%1:gr64 = COPY $eflags
OP1 may update eflags
$eflags = COPY %1
OP2 may use eflags
```

To use eflags as input at 4th instruction, we need to use SETcc to
preserve the eflags before 2, and update the source condition of OP2
according to value in GPR %1.

In this patch, we support CCMP/CTEST as OP2.

Ignore `ImplicitCastExpr` when building `AttrExp` for capability
attribute diagnostics.

Fixes: https://github.com/llvm/llvm-project/issues/92118.

```
.irp foo,1
nop
.endr
nop
```

expands to an excess EOL between two nop lines. Other loop directives
and .macro have the same issue.

`Lex()` at "Jump to the macro instantiation and prime the lexer"
requires that there is one single \n token in CurTok. Therefore, we
cannot consume the trailing \n when parsing the macro(-like) body.
(commit c6e787f7 (reverted by
1e5f29af))

Instead, skip the potential \n after jumpToLoc at handleMacroExit.

The purpose of this PR is to remove the 'etime-function.mlir' file that
I mistakenly committed in
https://github.com/llvm/llvm-project/pull/92571. This file is not
necessary in source code control, and its presence may cause confusion
or misunderstanding.

f3524e9a accidentally touched the
dependabot config. This patch reverts that change.

This reverts commit 881f20e9.

Passing -ldl -lpthread explicitly

This reverts commit 01f79899.

This unusual special case has been discussed on the binutils mailing
list. The approach will be revisited:
https://sourceware.org/pipermail/binutils/2024-May/134092.html

Pull Request: https://github.com/llvm/llvm-project/pull/92584

This reverts commit 487d5af6.

This was causing failures on some buildbots.
https://lab.llvm.org/buildbot/#/builders/247/builds/18559

In 0ec3b972 an additional restriction
was added when applying the `counted_by` attribute to flexible array
members in structs. The restriction prevented the element type being
a struct that itself had a flexible array member. E.g.:

```
struct has_unannotated_VLA {
  int count;
  char buffer[];
};

struct buffer_of_structs_with_unnannotated_vla {
  int count;
  struct has_unannotated_VLA Arr[] __counted_by(count);
};
```

In this example assuming the size of `Arr` is `sizeof(struct
has_unannotated_VLA)*count` (which is what the attribute says) is wrong
because it doesn't account for the size of
`has_unannotated_VLA::buffer`. This is why this kind of code construct
was treated as an error.

However, it turns out existing Linux kernel code used the attribute
on a flexible array member in this way
(https://github.com/llvm/llvm-project/pull/90786#issuecomment-2118416515).

To unbreak the build this restriction is downgraded to a warning with
the plan to make it an error again once the errornous use of the
attribute in the Linux kernel is resolved.

Out of tree we have other dialects that use the ring attribute, but we
get compilation errors when generating ops while pulling in all the
Polynomial tablegen ops (there's no `-dialect` flag in `mlir-tblgen` for
op generation like there is for attributes and types).

This PR simply moves the attributes into its own file, so it can be
included separately, and this also requires moving the dialect
declaration into its own file.

As was done recently to allow derived types that are not explicitly
BIND(C), but meet the requirements of BIND(C), to be acceptable for use
in contexts nominally requiring BIND(C), this patch allows procedures
that are not explicitly BIND(C) to be used in contexts that nominally
require BIND(C) so long as (1) they meet the requirements of BIND(C),
and (2) don't use dummy arguments whose implementations may vary under
BIND(C), such as VALUE.

For testing purposes the implementations of the output APIs like
OutputInteger32 have been simply constructing descriptors and executing
the operation through the general DescriptorIO template. This patch
decouples those APIs from that mechanism so that programs using simple
"PRINT *" statements for output can link to a smaller portion of the I/O
runtime support library. (This is the only form of I/O accepted in GPU
device code by previous CUDA Fortran and Fortran OpenACC compilers.)

This extends the NVPTX support for over-aligned parameters and return
values in a few related ways:

- Support for `alignstack` attribute, as an alternative to legacy nvvm
`!"align"` metadata entries. While we still maintain the legacy support,
long term it might be nice to auto-upgrade to `alignstack`.
- Check the alignment info when emitting the parameter list to prevent a
mismatch between alignment of caller and callee, which would previously
cause a fatal error for `ptxas`.
- Check the alignment info when emitting loads for parameters,
potentially enabling better vectorization.

Similar to a6d7828f

Bump the version to 0.2.1 to test the publishing workflow and update the
extension README and URL.