This commit adds a new flag to `ConversionConfig` that deactivates op folding during a dialect conversion. Op folding is problematic beause op folders may assume that the IR is in a valid state. (See #89770 for an example.) However, the dialect conversion driver does not guarantee that the IR is valid during a dialect conversion; it only guarantees that the IR is valid at the end of a dialect conversion. E.g., IR may be invalid after a conversion pattern application because some IR modifications (e.g., op/block replacements) are applied in a delayed fashion at the end of a dialect conversion. This makes op folders generally unsafe to use with a dialect conversion. Note: For the same reason, it is also not safe to use non-conversion patterns with a dialect conversion. Conversion patterns can be used safely because they have an "adapter". (And conversion patterns cannot assume that the entire IR is valid in general.)
This patch supports `G_CONSTANT_FOLD_BARRIER` on RISCV to generate the
following inst seq without crash:
```
define i64 @xor_and_i64(i64 %x) {
entry:
%y = and i64 %x, 16383
%z = xor i64 %y, 16368
ret i64 %z
}
```
In order to test SelectionDAG for target AMDGPU, we need CodeGenPassBuilder.
`__sanitizer_siginfo` has been introduced in D142117. (llvmorg-16-init-17950-ged9ef9b4f248) It is incompatible to -pedantic. `clang_rt.ctx_profile` has been introduced in #92456.
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.