Fix unicode build fail issue:
```
C4819 The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss ...\llvm-project\llvm\include\llvm\Support\Compiler.h
```
Now that VPlan is able to fold away redundant branches to the scalar
preheader, we can directly check in VPlan if the scalar tail may
execute. hasScalarTail returns true if the tail may execute.
We know that the scalar tail won't execute if the scalar preheader
doesn't have any predecessors, i.e. is not reachable.
This removes some late uses of the legacy cost model.
PR: https://github.com/llvm/llvm-project/pull/134674
These are problematic because the iterative application that locally
resolves the tensor.dim operation introduces
intermediate floor_div, which is losing the information about the exact
division that was carried out in the original
IR, and the iterative algorithm can't converge towards the simplest
form.
Information loss is not acceptable for canonicalization.
Resolving the dimOp can be achieved through
resolve-ranked-shaped-type-result-dims and
resolve-shaped-type-result-dims passes.
---------
Signed-off-by: Vivek Khandelwal <vivekkhandelwal1424@gmail.com>
This PR implements a CC1 flag `-dump-minimization-hints`.
The flag allows to specify a file path to dump ranges of deserialized
declarations in `ASTReader`. Example usage:
```
clang -Xclang=-dump-minimization-hints=/tmp/decls -c file.cc -o file.o
```
Example output:
```
// /tmp/decls
{
"required_ranges": [
{
"file": "foo.h",
"range": [
{
"from": {
"line": 26,
"column": 1
},
"to": {
"line": 27,
"column": 77
}
}
]
},
{
"file": "bar.h",
"range": [
{
"from": {
"line": 30,
"column": 1
},
"to": {
"line": 35,
"column": 1
}
},
{
"from": {
"line": 92,
"column": 1
},
"to": {
"line": 95,
"column": 1
}
}
]
}
]
}
```
Specifying the flag creates an instance of
`DeserializedDeclsSourceRangePrinter`, which dumps ranges of deserialized
declarations to aid debugging and bug minimization (we use is as input to [C-Vise](https://github.com/emaxx-google/cvise/tree/multifile-hints).
Required ranges are computed from source ranges of Decls.
`TranslationUnitDecl`, `LinkageSpecDecl` and `NamespaceDecl` are ignored
for the sake of this PR.
Technical details:
* `DeserializedDeclsSourceRangePrinter` implements `ASTConsumer` and
`ASTDeserializationListener`, so that an object of
`DeserializedDeclsSourceRangePrinter` registers as its own listener.
* `ASTDeserializationListener` interface provides the `DeclRead`
callback that we use to collect the deserialized Decls.
Printing or otherwise processing them as this point is dangerous, since
that could trigger additional deserialization and crash compilation.
* The collected Decls are processed in `HandleTranslationUnit` method of
`ASTConsumer`. This is a safe point, since we know that by this point
all the Decls needed by the compiler frontend have been deserialized.
* In case our processing causes further deserialization, `DeclRead` from
the listener might be called again. However, at that point we don't
accept any more Decls for processing.
The type traits are always `struct`s, so the `public` isn't necessary.
We're currently using `public` in some places, while we omit it in
others. This makes us consistent across the type traits.
Same cleanup as in https://github.com/llvm/llvm-project/pull/135031. It
pretty much is the same code that we had to duplicate in the language
plugin. Maybe eventually we'll find a way of getting rid of the
duplication.
We already did this for constant cases, this patch generalizes the existing fold to attempt to extract the splat from either operand of a ADD node for the gather/scatter index value
This cleanup should also make it easier to add support for splitting vXi32 indices on x86_64 64-bit pointer targets in the future as well.
Noticed while reviewing #134979
getConstVector could only handle f32/f64 vector element types from raw APInt bit data - instead of trying to add all supported fp types, just bitcast the integer equivalent and leave it to getNode/FoldConstantArithmetic to perform the constant bitcast conversion
Tentative fix for a regression reported after #133913
When REVEC is enabled, ScalarTy may be a FixedVectorType. Compare its
element type to decide if casting is needed. Also apply mask
transformation accordingly.
PowerPC uses a slightly different type of floats for their 128 bit long
doubles, as "double-double", with __LDBL_MANT_DIG__ == 106 rather than
__LDBL_MANT_DIG__ == 113 for IEEE 128 bit floats.
This fixes compiling libcxxabi for PowerPC after
3b70715c13876c51542ebfe2e3f4ee908f6785cb.
Fix comparing type id pointers, add mor info when print()ing them, use
the most derived type in GetTypeidPtr() and the canonically unqualified
type when we know the type statically.
PR #82952 introduced regex matching for `CheckedFunctions` in
`UnusedReturnValueCheck` which is used by the checker `cert-err33-c`.
Add a testcase and fix false positives by adding end-of-string to target
regex's.
---------
Signed-off-by: Björn Svensson <bjorn.a.svensson@est.tech>
Addition of `inlinehint` attributes for CallOps in MLIR in order to be
able to say to a function call that the inlining is desirable without
having the attribute on the FuncOp.
.. which prepares us for handling of discontinuous functions. The main
change there is that we can have multiple FDEs contributing towards an
unwind plan of a single function. This patch separates the logic for
parsing of a single FDE from the construction of an UnwindPlan (so that
another patch can change the latter to combine several unwind plans).
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This crash will caused if run this testcase:
llvm/test/CodeGen/AMDGPU/llvm.amdgcn.ds.gws.barrier-fastregalloc.ll
When build the SDNode, precisely build the SDNode for this ir:
```ir
call void @llvm.amdgcn.ds.gws.barrier(i32 %val, i32 0)
```
If want call the dump function of the new SDNode in the gdb environment
like this:
```gdb
p N->dump()
```
The llvm will crash.
All of these is because calling ```dump()``` will cause the
calling```MachineMemOperand::print()```
with the argument value for the```TII``` is nullptr.
And the llvm/lib/CodeGen/MachineOperand.cpp#L1235 is a derefrence of
TII.
Signed-off-by: fanfuqiang <fuqiang.fan@mthreads.com>
This is a follow-up to https://github.com/llvm/llvm-project/pull/131074.
After moving the default argument heuristic to `simplifyType` in that
patch, the heuristic no longer applied to the
`DependentScopeDeclRefExpr` case, because that wasn't using
`simplifyType`.
This patch fixes that, with an added testcase.
This patch adds support for parsing symbols in the Xqcilb long branch
instructions. The instructions use the `R_RISCV_QC_E_JUMP_PLT`
relocation and the `InstFormatQC_EJ` instruction format.
Vendor relocation support will be added in a later patch.
This avoids needing to hardcode the mapping between architectures and
their sizes of long doubles.
This fixes a case in test_demangle.pass.cpp, that previously failed like
this (XFAILed):
.---command stdout------------
| Testing 29859 symbols.
| _ZN5test01hIfEEvRAcvjplstT_Le4001a000000000000000E_c should be invalid
but is not
| Got: 0, void test0::h<float>(char (&) [(unsigned int)(sizeof (float) +
0x0.07ff98f7ep-1022L)])
`-----------------------------
.---command stderr------------
| Assertion failed: !passed && "demangle did not fail", file
libcxxabi/test/test_demangle.pass.cpp, line 30338
`-----------------------------
This testcase is defined within
// Is long double fp80? (Only x87 extended double has 64-bit mantissa)
#define LDBL_FP80 (__LDBL_MANT_DIG__ == 64)
...
#if !LDBL_FP80
...
#endif
The case failed on x86 architectures with an unusual size for long
doubles, as the test expected the demangler to not be able to demangle
an 80 bit long double (based on the `__LDBL_MANT_DIG__ == 64` condition
in the test). However as the libcxxabi implementation was hardcoded to
demangle 80 bit long doubles on x86_64 regardless of the actual size,
this test failed (by unexpectedly being able to demangle it).
By configuring libcxxabi's demangling of long doubles to match what the
compiler specifies, we no longer hit the expected failures in the
test_demangle.pass.cpp test on Android on x86.
This makes libcxxabi require a GCC-compatible compiler that defines
nonstandard defines like `__LDBL_MANT_DIG__`, but I presume that's
already essentially required anyway.
... to clarify ownership, aligning with other parameters. Using
`std::unique_ptr` encourages users to manage `createMCInstPrinter` with
a unique_ptr instead of a raw pointer, reducing the risk of memory
leaks.
* llvm-mc: fix a leak and update llvm/test/tools/llvm-mc/disassembler-options.test
* #121078 copied the llvm-mc code to CodeGenTargetMachineImpl and made
the same mistake. Fixed by 2b8cc651dca0c000ee18ec79bd5de4826156c9d6
Using unique_ptr requires #include MCInstPrinter.h in a few translation
units.
* Delete a createAsmStreamer overload I deprecated in 2024
* SystemZMCTargetDesc.cpp: rename to `createSystemZAsmStreamer` to fix
an overload conflict.
Pull Request: https://github.com/llvm/llvm-project/pull/135128
This can be done with a vrgather.vi/vx, and (possibly) a register move.
The alternative is to do a vrgather.vv with a full width index vector.
We'd already caught the two operands forms of this shuffle; this patch
specifically handles the single operand form.
Unfortunately only in abstract, it would be nice if we canonicalized
shuffles in some way wouldn't it?
Fixes error: ISO C++20 considers use of overloaded operator '==' (with
operand types 'MacosVersion' and 'MacosVersion') to be ambiguous despite
there being a unique best viable function
[-Werror,-Wambiguous-reversed-operator].
This converts the comparison operator from a non-symmetric operator
(const VersionBase<VersionType>& (as "this") and const VersionType &).
into a symmetric operator
Relands #135068
Co-authored-by: Ivan Tadeu Ferreira Antunes Filho <antunesi@google.com>
This patch defines `fir::SafeTempArrayCopyAttrInterface` and the
corresponding
OpenACC/OpenMP related attributes in FIR dialect. The actual
implementations
are just placeholders right now, and array repacking becomes a no-op
if `-fopenacc/-fopenmp` is used for the compilation.
The NVVMReflect pass simply replaces calls to nvvm-reflect functions
with the appropriate constant, either the architecture number, or
nvvm-reflect-ftz, found in the module's metadata.
The implementation is inefficient and does this by traversing through
all instructions to find calls. The common case is that you never call
nvvm-reflect, so this traversal is costly.
This PR:
- Updates the pass so that it finds the reflect functions by name, and
then traverses through their uses to find the calls directly.
- Adds a line (245) to make sure the dead nvvm-reflect definitions are
erased.
- Adds the ability to set reflect values via command line
In the LLVM middle-end we want to fold `gep inbounds null, idx -> null`:
https://alive2.llvm.org/ce/z/5ZkPx-
This pattern is common in real-world programs
(https://github.com/dtcxzyw/llvm-opt-benchmark/pull/55#issuecomment-1870963906).
Generally, it exists in some (actually) unreachable blocks, which is
introduced by JumpThreading.
However, some old-style offsetof macros are still widely used in
real-world C/C++ code (e.g., hwloc/slurm/luajit). To avoid breaking
existing code and inconvenience to downstream users, this patch removes
the inbounds flag from the struct gep if the base pointer is null.
`WidenIV::widenWithVariantUse` assumes that exactly one of the binop
operands is the IV to be widened. This miscompilation happens when it
tries to sign-extend the "NonIV" operand while the IV is zero-extended.
Closes https://github.com/llvm/llvm-project/issues/135182.
