Originally, the intent behind symtab was to represent the symbol table
seen in the PE header (without applying ARM64X relocations). However, in
most cases outside of `writeHeader()`, the code references either both
symbol tables or only the EC one, for example, `mainSymtab` in
`linkerMain()` maps to `hybridSymtab` on ARM64X.
MSVC's link.exe allows pure ARM64EC images to include native ARM64
files. This patch prepares LLD to support the same, which will require
`hybridSymtab` to be available even for ARM64EC. At that point,
`writeHeader()` will need to use the EC symbol table, and the original
reasoning for keeping it in `hybridSymtab` no longer applies.
Given this, it seems cleaner to treat the EC symbol table as the “main”
one, assigning it to `symtab`, and use `hybridSymtab` for the native
symbol table instead. Since `writeHeader()` will need to be conditional
anyway, this change simplifies the rest of the code by allowing other
parts to consistently treat `ctx.symtab` as the main symbol table.
As a further simplification, this also allows us to eliminate `symtabEC`
and use `symtab` directly; I’ll submit that as a separate PR.
The map file now uses the EC symbol table for printed entry points and
exports, matching MSVC behavior.
If the buildvector node contains constants and non-constants, need to
consider shuffling of the constant vec and insertion of unique elements
into the vector. Also, if there is an input vector, need to consider the
cost of shuffling source vector and constant vector and then insertion
and shuffling of the non-constant elements.
Reviewers: hiraditya, RKSimon
Reviewed By: RKSimon
Pull Request: https://github.com/llvm/llvm-project/pull/135245
This reverts commit d1156fcb56891fb1a426c3e8331a51d47f98a1b8.
This patch fixes the reported incorrect formatting changes and adds
tests for them. The performance should be unaffected, since there are no
significant changes required to fix the bugs.
Specifically, a `>` was changed to a `>=` to also add a `+` in the zero
case, and we're checking for zero now before printing the octal and
hexadecimal prefixes.
Closes#131710
This PR accounts for scaled reductions in `calculateRegisterUsage` to
reflect the fact that the number of lanes in their output is smaller
than the VF.
Depends on https://github.com/llvm/llvm-project/pull/126437
Original in https://github.com/llvm/llvm-project/pull/134626 was
written as if it was "this or this" but it's "this and this".
So the test ran on AArch64 Linux, because Linux is not Windows.
Split out the Windows check to fix that.
Ops that are already snake case (like [`ROCDL_wmma_*`
ops](66b0b0466b/mlir/include/mlir/Dialect/LLVMIR/ROCDLOps.td (L411)))
produce python "value-builders" that collide with the class names:
```python
class wmma_bf16_16x16x16_bf16(_ods_ir.OpView):
OPERATION_NAME = "rocdl.wmma.bf16.16x16x16.bf16"
...
def wmma_bf16_16x16x16_bf16(res, args, *, loc=None, ip=None) -> _ods_ir.Value:
return wmma_bf16_16x16x16_bf16(res=res, args=args, loc=loc, ip=ip).result
```
and thus cannot be emitted (because of recursive self-calls).
This PR fixes that by affixing `_` to the value builder names.
I would've preferred to just rename the ops but that would be a breaking
change 🤷.
When you call the `SBTarget::ReadInstructions` with flavor from lldb
crashes. This is because the wrong order of the `DisassemblyBytes`
constructor this fixes that
---------
Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
One was "unsafe use of bool" and the other was "sign comparision
mismatch", and both were because we're treating a bool object as if it
were an unsigned int. Add a cast to make that more explicit.
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.
