Skip to content

Conversation

@Stylie777
Copy link
Owner

[libc][math] Disable FEnvSafeTest.cpp if AArch64 target has no FP support (llvm#166370)

The FEnvSafeTest.cpp test fails on AArch64 soft nofp configurations
because LLVM libc does not provide a floating-point environment in these
configurations.

This patch adds another preprocessor guard on __ARM_FP to disable the
test on those.

[clang][bytecode] Remove dummy variables once they are proper globals (llvm#166174)

Dummy variables have an entry in Program::Globals, but they are not
added to GlobalIndices. When registering redeclarations, we used to
only patch up the global indices, but that left the dummy variables
alone. Update the dummy variables of all redeclarations as well.

Fixes llvm#165952

[clang-tidy][doc] add more information in twine-local's document (llvm#166266)

explain more about use-after-free in llvm-twine-local
add note about manually adjusting code after applying fix-it.
fixed: llvm#154810

[CIR] Add support for storing into _Atomic variables (llvm#165872)

[mlir] Dialect Conversion: Add support for post-order legalization order (llvm#166292)

By default, the dialect conversion driver processes operations in
pre-order: the initial worklist is populated pre-order. (New/modified
operations are immediately legalized recursively.)

This commit adds a new API for selective post-order legalization.
Patterns can request an operation / region legalization via
ConversionPatternRewriter::legalize. They can call these helper
functions on nested regions before rewriting the operation itself.

Note: In rollback mode, a failed recursive legalization typically leads
to a conversion failure. Since recursive legalization is performed by
separate pattern applications, there is no way for the original pattern
to recover from such a failure.

[mlir][LLVM] Fix unsupported FP lowering in VectorConvertToLLVMPattern (llvm#166513)

Fixes a bug in VectorConvertToLLVMPattern, which converted operations
with unsupported FP types. E.g., arith.addf ... : f4E2M1FN was lowered
to llvm.fadd ... : i4, which does not verify. There are a few more
patterns that have the same bug. Those will be fixed in follow-up PRs.

This commit is in preparation of adding an APFloat-based lowering for
arith operations with unsupported floating-point types.

[utils][UpdateLLCTestChecks] Add MIR support to update_llc_test_checks.py. (llvm#164965)

This change enables update_llc_test_checks.py to automatically generate
MIR checks for RUN lines that use -stop-before or -stop-after flags
allowing tests to verify intermediate compilation stages (e.g., after
instruction selection but before peephole optimizations) alongside the
final assembly output. If -debug-only flag is present in the run line it's
considered as the main point of interest for testing and stop flags above
are ignored (that is no MIR checks are generated).

This resulted from the scenario, when I needed to test two instruction
matching patterns where the later pattern in the peepholer reverts the
earlier pattern in the instruction selector and distinguish it from the
case when the earlier pattern didn't worked at all.

Initially created by Claude Sonnet 4.5 it was improved later to handle
conflicts in MIR <-> ASM prefixes and formatting.

[llvm][LoongArch] Introduce LASX and LSX conversion intrinsics (llvm#157818)

This patch introduces the LASX and LSX conversion intrinsics:

  • <8 x float> @llvm.loongarch.lasx.cast.128.s(<4 x float>)
  • <4 x double> @llvm.loongarch.lasx.cast.128.d(<2 x double>)
  • <4 x i64> @llvm.loongarch.lasx.cast.128(<2 x i64>)
  • <8 x float> @llvm.loongarch.lasx.concat.128.s(<4 x float>, <4 x
    float>)
  • <4 x double> @llvm.loongarch.lasx.concat.128.d(<2 x double>, <2 x
    double>)
  • <4 x i64> @llvm.loongarch.lasx.concat.128(<2 x i64>, <2 x i64>)
  • <4 x float> @llvm.loongarch.lasx.extract.128.lo.s(<8 x float>)
  • <2 x double> @llvm.loongarch.lasx.extract.128.lo.d(<4 x double>)
  • <2 x i64> @llvm.loongarch.lasx.extract.128.lo(<4 x i64>)
  • <4 x float> @llvm.loongarch.lasx.extract.128.hi.s(<8 x float>)
  • <2 x double> @llvm.loongarch.lasx.extract.128.hi.d(<4 x double>)
  • <2 x i64> @llvm.loongarch.lasx.extract.128.hi(<4 x i64>)
  • <8 x float> @llvm.loongarch.lasx.insert.128.lo.s(<8 x float>, <4 x
    float>)
  • <4 x double> @llvm.loongarch.lasx.insert.128.lo.d(<4 x double>, <2 x
    double>)
  • <4 x i64> @llvm.loongarch.lasx.insert.128.lo(<4 x i64>, <2 x i64>)
  • <8 x float> @llvm.loongarch.lasx.insert.128.hi.s(<8 x float>, <4 x
    float>)
  • <4 x double> @llvm.loongarch.lasx.insert.128.hi.d(<4 x double>, <2 x
    double>)
  • <4 x i64> @llvm.loongarch.lasx.insert.128.hi(<4 x i64>, <2 x i64>)

[gn] port 0c73009

[libc][math] Refactor exp2m1f16 implementation to header-only in src/__support/math folder. (llvm#162019)

Part of llvm#147386

in preparation for: https://discourse.llvm.org/t/rfc-make-clang-builtin-math-functions-constexpr-with-llvm-libc-to-support-c-23-constexpr-math-functions/86450

[clang-tidy][NFC] Fix broken link in bugprone-default-operator-new-on-overaligned-type (llvm#166546)

[Clang][NFC] Refactor SemaCXX/dllexport.cpp to use -verify= instead of macros (llvm#165855)

[RISCV] Add a test for multiple save locations of a callee-saved register (llvm#164479)

Technically, it is possible that the a callee-saved register is saved in
different locations. CFIInstrInserter should handle this, but currently
it does not.

[VPlan] Avoid sinking allocas in sinkScalarOperands (llvm#166135)

Use cannotHoistOrSinkRecipe to forbid sinking allocas.

[Polly] Check for ISL errors after schedule optimization (llvm#166551)

When ISL encounters an internal error, it sets the error flag, but it is
not isl_error_quota that was already checked. Check for general errors
and abort the schedule optimization if that happens, instead of
continuing on the good path.

The error occured when compiling llvm-test-suite's
MultiSource/Applications/JM/lencod/leaky_bucket.c with Polly enabled.
Not adding a test case because it depends on ISL internals. We do not
want to a test case to depend on which version of ISL is used.

Revert "[utils][UpdateLLCTestChecks] Add MIR support to update_llc_test_checks.py." (llvm#166549)

Reverts llvm#164965

[X86] Add test coverage for llvm#166534 (llvm#166552)

[Clang][ARM] Fix tests using thumb instead arm arch on cc1 (llvm#166416)

Currently, the ARM backend incorrectly parses every arm prefixed arch
to be non-thumb, but armv6m is THUMB and doesnt have ARM ops causing
the test to fail when compiling to assembly and not LLVM IR: error: Function 'foo' uses ARM instructions, but the target does not support ARM mode execution. This only happens when invoking cc1 directly and
not the Clang driver.

As a quick triage, this patch changes the tests to use thumb.

Uncovered by llvm#151404

[RISCV] Introduce pass to promote double constants to a global array (llvm#160536)

As discussed in llvm#153402, we have inefficiences in handling constant pool
access that are difficult to address. Using an IR pass to promote double
constants to a global allows a higher degree of control of code
generation for these accesses, resulting in improved performance on
benchmarks that might otherwise have high register pressure due to
accessing constant pool values separately rather than via a common base.

Directly promoting double constants to separate global values and
relying on the global merger to do a sensible thing would be one
potential avenue to explore, but it is not done in this version of the
patch because:

  • The global merger pass needs fixes. For instance it claims to be a
    function pass, yet all of the work is done in initialisation. This means
    that attempts by backends to schedule it after a given module pass don't
    actually work as expected.
  • The heuristics used can impact codegen unexpectedly, so I worry that
    tweaking it to get the behaviour desired for promoted constants may lead
    to other issues. This may be completely tractable though.

Now that llvm#159352 has landed, the impact on terms if dynamically executed
instructions is slightly smaller (as we are starting from a better
baseline), but still worthwhile in lbm and nab from SPEC. Results below
are for rva22u64:

Benchmark                  Baseline         This PR   Diff (%)
============================================================
============================================================
500.perlbench_r         180668945687    180666122417     -0.00%
502.gcc_r               221274522161    221277565086      0.00%
505.mcf_r               134656204033    134656204066      0.00%
508.namd_r              217646645332    216699783858     -0.44%
510.parest_r            291731988950    291916190776      0.06%
511.povray_r             30983594866     31107718817      0.40%
519.lbm_r                91217999812     87405361395     -4.18%
520.omnetpp_r           137699867177    137674535853     -0.02%
523.xalancbmk_r         284730719514    284734023366      0.00%
525.x264_r              379107521547    379100250568     -0.00%
526.blender_r           659391437610    659447919505      0.01%
531.deepsjeng_r         350038121654    350038121656      0.00%
538.imagick_r           238568674979    238560772162     -0.00%
541.leela_r             405660852855    405654701346     -0.00%
544.nab_r               398215801848    391352111262     -1.72%
557.xz_r                129832192047    129832192055      0.00%


Notes for reviewers:

  • As discussed at the sync-up meeting, the suggestion is to try to land
    an incremental improvement to the status quo even if there is more work
    to be done around the general issue of constant pool handling. We can
    discuss here if that is actually the best next step or not, but I just
    wanted to clarify that's why this is being posted with a somewhat narrow
    scope.
  • I've disabled transformations both for RV32 and on systems without D
    as both cases saw some regressions.

[clang][NFC] Rename stale TypeSourceInfo DI variables (llvm#166082)

Fixes llvm#165346

This patch renames stale variable names where TypeSourceInfo objects
were still using the old DI (DeclaratorInfo) naming convention.

Specifically, variables of type TypeSourceInfo have been updated from
DI to TSI to improve code clarity and maintain consistency with the
current naming.

[DebugInfo] Assign best possible debugloc to bundle (llvm#164573)

The debug info attached to the BUNDLE is the first instruction in the
BUNDLE, even if a better debug info (line:column) is present in the
later instructions of the bundle. The patch tries to get a better debug
info first. If not, then a worse debug info without line number is
chosen.


Co-authored-by: Vladislav Dzhidzhoev [email protected]
Co-authored-by: Orlando Cazalet-Hyams [email protected]

[clang][bytecode] Check types when loading values (llvm#165385)

We need to allow BitCasts between pointer types to different prim types,
but that means we need to catch the problem at a later stage, i.e. when
loading the values.

Fixes llvm#158527
Fixes llvm#163778

DAG: Avoid some libcall string name comparisons (llvm#166321)

Move to the libcall impl based functions.

[PowerPC][NFC] auto gen checks vec rounding tests (llvm#166435)

Update tests to contain auto generated checks.

[MLIR][NVVM] Fix the lowering of mbarrier.test.wait (llvm#166555)

PR llvm#165993 accidentally broke the lowering of the test.wait Op.

This patch fixes the issue and adds tests to verify the lowering to
intrinsics for all mbarrier Ops, ensuring similar regressions are caught in the
future.

Additionally, the cp-async-mbarrier test is moved to the
mbarriers.mlir test file to keep all related tests together.

Signed-off-by: Durgadoss R [email protected]

[BOLT][NFC] Rename funtions with _negative suffix to _unknown when th… (llvm#166536)

…e size is unknown

Keep _negative suffix only for test cases when the size is negative

[flang] Adding NOTIFY specifier in image selector and add notify type checks (llvm#148810)

This PR adds support for the NOTIFY specifier in the image selector as
described in the 2023 standard, and add checks for the NOTIFY_TYPE type.

[ProfCheck][NFC] Make Function argument from branch weight setter optional (llvm#166032)

This picks up from llvm#166028, making the Function argument optional:
most cases don't need to provide it, but in e.g. InstCombine's case,
where the instruction (select, branch) is not attached to a function
yet, the function needs to be passed explicitly.

Co-authored-by: Florian Hahn [email protected]

[gn] port bb4ed55

[Clang] FunctionEffects: ignore (methods of) local CXXRecordDecls. (llvm#166078)

In the following example, Functor::method() inappropriately triggers a
diagnostic that outer() is blocking by allocating memory.

void outer() [[clang::nonblocking]]
{
	struct Functor {
		int* ptr;
		
		void method() { ptr = new int; }
	};
}

Co-authored-by: Doug Wyatt [email protected]

[NFC][TableGen] Adopt NamespaceEmitter in DirectiveEmitter (llvm#165600)

[MsDemangle] Read entire chain of target names in special tables (llvm#155630)

When there's a deep inheritance hierarchy of multiple C++ classes (see
below), then the mangled name of a VFTable can include multiple key
nodes in the target name.
For example, in the following code, MSVC will generate mangled names for
the VFTables that have up to three key classes in the context.

Code
class Base1 {
  virtual void a() {};
};
class Base2 {
  virtual void b() {}
};

class Ind1 : public Base1 {};
class Ind2 : public Base1 {};

class A : public Ind1, public Ind2 {};

class Ind3 : public A {};
class Ind4 : public A {};

class B : public Ind3, public Ind4 {};

class Ind5 : public B {};
class Ind6 : public B {};

class C : public Ind5, public Ind6 {};

int main() { auto i = new C; }

This will include ??_7C@@6BInd1@@Ind4@@Ind5@@@ (and every other
combination). Microsoft's undname will demangle this to "const
C::`vftable'{for `Ind1's `Ind4's `Ind5'}". Previously, LLVM would
demangle this to "const C::`vftable'{for `Ind1'}".

With this PR, the output of LLVM's undname will be identical to
Microsoft's version. This changes SpecialTableSymbolNode::TargetName
to a node array which contains each key from the name. Unlike
namespaces, these keys are not in reverse order - they are in the same
order as in the mangled name.

Fix failures introduced in llvm#166032 (llvm#166574)

[gn build] Port 3700587

[gn build] Port 3ebed51

[gn build] Port 51d0f6d

[gn build] Port 718a3b2

[gn build] Port dd14eb8

[Flang][OpenMP] Add Lowering support for taskloop reductions

Support for lowering the Reduction clause support already exists,
so we can extend the support for taskloop to include reduction.

As support for Reduction in taskloop was only added in OpenMP 5.0,
the use of the Clause has been restricted to that version of OpenMP
or greater.

vhscampos and others added 30 commits November 5, 2025 11:14
…upport (llvm#166370)

The `FEnvSafeTest.cpp` test fails on AArch64 soft nofp configurations
because LLVM libc does not provide a floating-point environment in these
configurations.

This patch adds another preprocessor guard on `__ARM_FP` to disable the
test on those.
…llvm#166174)

Dummy variables have an entry in `Program::Globals`, but they are not
added to `GlobalIndices`. When registering redeclarations, we used to
only patch up the global indices, but that left the dummy variables
alone. Update the dummy variables of all redeclarations as well.


Fixes llvm#165952
…m#166266)

explain more about use-after-free in llvm-twine-local
add note about manually adjusting code after applying fix-it.
fixed: llvm#154810
…der (llvm#166292)

By default, the dialect conversion driver processes operations in
pre-order: the initial worklist is populated pre-order. (New/modified
operations are immediately legalized recursively.)

This commit adds a new API for selective post-order legalization.
Patterns can request an operation / region legalization via
`ConversionPatternRewriter::legalize`. They can call these helper
functions on nested regions before rewriting the operation itself.

Note: In rollback mode, a failed recursive legalization typically leads
to a conversion failure. Since recursive legalization is performed by
separate pattern applications, there is no way for the original pattern
to recover from such a failure.
…rn` (llvm#166513)

Fixes a bug in `VectorConvertToLLVMPattern`, which converted operations
with unsupported FP types. E.g., `arith.addf ... : f4E2M1FN` was lowered
to `llvm.fadd ... : i4`, which does not verify. There are a few more
patterns that have the same bug. Those will be fixed in follow-up PRs.

This commit is in preparation of adding an `APFloat`-based lowering for
`arith` operations with unsupported floating-point types.
…s.py. (llvm#164965)

This change enables update_llc_test_checks.py to automatically generate
MIR checks for RUN lines that use `-stop-before` or `-stop-after` flags
allowing tests to verify intermediate compilation stages (e.g., after
instruction selection but before peephole optimizations) alongside the
final assembly output. If `-debug-only` flag is present in the run line it's
considered as the main point of interest for testing and stop flags above
are ignored (that is no MIR checks are generated).

This resulted from the scenario, when I needed to test two instruction
matching patterns where the later pattern in the peepholer reverts the
earlier pattern in the instruction selector and distinguish it from the
case when the earlier pattern didn't worked at all.

Initially created by Claude Sonnet 4.5 it was improved later to handle
conflicts in MIR <-> ASM prefixes and formatting.
…157818)

This patch introduces the LASX and LSX conversion intrinsics:

- <8 x float> @llvm.loongarch.lasx.cast.128.s(<4 x float>)
- <4 x double> @llvm.loongarch.lasx.cast.128.d(<2 x double>)
- <4 x i64> @llvm.loongarch.lasx.cast.128(<2 x i64>)
- <8 x float> @llvm.loongarch.lasx.concat.128.s(<4 x float>, <4 x
float>)
- <4 x double> @llvm.loongarch.lasx.concat.128.d(<2 x double>, <2 x
double>)
- <4 x i64> @llvm.loongarch.lasx.concat.128(<2 x i64>, <2 x i64>)
- <4 x float> @llvm.loongarch.lasx.extract.128.lo.s(<8 x float>)
- <2 x double> @llvm.loongarch.lasx.extract.128.lo.d(<4 x double>)
- <2 x i64> @llvm.loongarch.lasx.extract.128.lo(<4 x i64>)
- <4 x float> @llvm.loongarch.lasx.extract.128.hi.s(<8 x float>)
- <2 x double> @llvm.loongarch.lasx.extract.128.hi.d(<4 x double>)
- <2 x i64> @llvm.loongarch.lasx.extract.128.hi(<4 x i64>)
- <8 x float> @llvm.loongarch.lasx.insert.128.lo.s(<8 x float>, <4 x
float>)
- <4 x double> @llvm.loongarch.lasx.insert.128.lo.d(<4 x double>, <2 x
double>)
- <4 x i64> @llvm.loongarch.lasx.insert.128.lo(<4 x i64>, <2 x i64>)
- <8 x float> @llvm.loongarch.lasx.insert.128.hi.s(<8 x float>, <4 x
float>)
- <4 x double> @llvm.loongarch.lasx.insert.128.hi.d(<4 x double>, <2 x
double>)
- <4 x i64> @llvm.loongarch.lasx.insert.128.hi(<4 x i64>, <2 x i64>)
…ster (llvm#164479)

Technically, it is possible that the a callee-saved register is saved in
different locations. CFIInstrInserter should handle this, but currently
it does not.
Use cannotHoistOrSinkRecipe to forbid sinking allocas.
When ISL encounters an internal error, it sets the error flag, but it is
not isl_error_quota that was already checked. Check for general errors
and abort the schedule optimization if that happens, instead of
continuing on the good path.

The error occured when compiling llvm-test-suite's
MultiSource/Applications/JM/lencod/leaky_bucket.c with Polly enabled.
Not adding a test case because it depends on ISL internals. We do not
want to a test case to depend on which version of ISL is used.
Currently, the ARM backend incorrectly parses every `arm` prefixed arch
to be non-thumb, but `armv6m` is THUMB and doesnt have ARM ops causing
the test to fail when compiling to assembly and not LLVM IR: `error:
Function 'foo' uses ARM instructions, but the target does not support
ARM mode execution.` This only happens when invoking cc1 directly and
not the Clang driver.

As a quick triage, this patch changes the tests to use `thumb`.

Uncovered by llvm#151404
…lvm#160536)

As discussed in llvm#153402, we have inefficiences in handling constant pool
access that are difficult to address. Using an IR pass to promote double
constants to a global allows a higher degree of control of code
generation for these accesses, resulting in improved performance on
benchmarks that might otherwise have high register pressure due to
accessing constant pool values separately rather than via a common base.

Directly promoting double constants to separate global values and
relying on the global merger to do a sensible thing would be one
potential avenue to explore, but it is _not_ done in this version of the
patch because:
* The global merger pass needs fixes. For instance it claims to be a
function pass, yet all of the work is done in initialisation. This means
that attempts by backends to schedule it after a given module pass don't
actually work as expected.
* The heuristics used can impact codegen unexpectedly, so I worry that
tweaking it to get the behaviour desired for promoted constants may lead
to other issues. This may be completely tractable though.

Now that llvm#159352 has landed, the impact on terms if dynamically executed
instructions is slightly smaller (as we are starting from a better
baseline), but still worthwhile in lbm and nab from SPEC. Results below
are for rva22u64:

```
Benchmark                  Baseline         This PR   Diff (%)
============================================================
============================================================
500.perlbench_r         180668945687    180666122417     -0.00%
502.gcc_r               221274522161    221277565086      0.00%
505.mcf_r               134656204033    134656204066      0.00%
508.namd_r              217646645332    216699783858     -0.44%
510.parest_r            291731988950    291916190776      0.06%
511.povray_r             30983594866     31107718817      0.40%
519.lbm_r                91217999812     87405361395     -4.18%
520.omnetpp_r           137699867177    137674535853     -0.02%
523.xalancbmk_r         284730719514    284734023366      0.00%
525.x264_r              379107521547    379100250568     -0.00%
526.blender_r           659391437610    659447919505      0.01%
531.deepsjeng_r         350038121654    350038121656      0.00%
538.imagick_r           238568674979    238560772162     -0.00%
541.leela_r             405660852855    405654701346     -0.00%
544.nab_r               398215801848    391352111262     -1.72%
557.xz_r                129832192047    129832192055      0.00%

```

---
Notes for reviewers:
* As discussed at the sync-up meeting, the suggestion is to try to land
an incremental improvement to the status quo even if there is more work
to be done around the general issue of constant pool handling. We can
discuss here if that is actually the best next step or not, but I just
wanted to clarify that's why this is being posted with a somewhat narrow
scope.
* I've disabled transformations both for RV32 and on systems without D
as both cases saw some regressions.
Fixes llvm#165346

This patch renames stale variable names where `TypeSourceInfo` objects
were still using the old `DI` (`DeclaratorInfo`) naming convention.

Specifically, variables of type `TypeSourceInfo` have been updated from
`DI` to `TSI` to improve code clarity and maintain consistency with the
current naming.
The debug info attached to the BUNDLE is the first instruction in the
BUNDLE, even if a better debug info (line:column) is present in the
later instructions of the bundle. The patch tries to get a better debug
info first. If not, then a worse debug info without line number is
chosen.

---------

Co-authored-by: Vladislav Dzhidzhoev <[email protected]>
Co-authored-by: Orlando Cazalet-Hyams <[email protected]>
We need to allow BitCasts between pointer types to different prim types,
but that means we need to catch the problem at a later stage, i.e. when
loading the values.

Fixes llvm#158527
Fixes llvm#163778
Move to the libcall impl based functions.
Update tests to contain auto generated checks.
PR llvm#165993 accidentally broke the lowering of the `test.wait` Op.

This patch fixes the issue and adds tests to verify the lowering to
intrinsics for all mbarrier Ops, ensuring similar regressions are caught in the
future.

Additionally, the `cp-async-mbarrier` test is moved to the
`mbarriers.mlir` test file to keep all related tests together.

Signed-off-by: Durgadoss R <[email protected]>
llvm#166536)

…e size is unknown

Keep _negative suffix only for test cases when the size is negative
… checks (llvm#148810)

This PR adds support for the NOTIFY specifier in the image selector as
described in the 2023 standard, and add checks for the NOTIFY_TYPE type.
…ional (llvm#166032)

This picks up from llvm#166028, making the `Function` argument optional:
most cases don't need to provide it, but in e.g. InstCombine's case,
where the instruction (select, branch) is not attached to a function
yet, the function needs to be passed explicitly.

Co-authored-by: Florian Hahn <[email protected]>
…lvm#166078)

In the following example, `Functor::method()` inappropriately triggers a
diagnostic that `outer()` is blocking by allocating memory.

```
void outer() [[clang::nonblocking]]
{
	struct Functor {
		int* ptr;
		
		void method() { ptr = new int; }
	};
}
```

---------

Co-authored-by: Doug Wyatt <[email protected]>
jurahul and others added 9 commits November 5, 2025 07:46
…m#155630)

When there's a deep inheritance hierarchy of multiple C++ classes (see
below), then the mangled name of a VFTable can include multiple key
nodes in the target name.
For example, in the following code, MSVC will generate mangled names for
the VFTables that have up to three key classes in the context.
<details><summary>Code</summary>

```cpp
class Base1 {
  virtual void a() {};
};
class Base2 {
  virtual void b() {}
};

class Ind1 : public Base1 {};
class Ind2 : public Base1 {};

class A : public Ind1, public Ind2 {};

class Ind3 : public A {};
class Ind4 : public A {};

class B : public Ind3, public Ind4 {};

class Ind5 : public B {};
class Ind6 : public B {};

class C : public Ind5, public Ind6 {};

int main() { auto i = new C; }
```
</details> 

This will include `??_7C@@6BInd1@@ind4@@ind5@@@` (and every other
combination). Microsoft's undname will demangle this to "const
C::\`vftable'{for \`Ind1's \`Ind4's \`Ind5'}". Previously, LLVM would
demangle this to "const C::\`vftable'{for \`Ind1'}".

With this PR, the output of LLVM's undname will be identical to
Microsoft's version. This changes `SpecialTableSymbolNode::TargetName`
to a node array which contains each key from the name. Unlike
namespaces, these keys are not in reverse order - they are in the same
order as in the mangled name.
Support for lowering the Reduction clause support already exists,
so we can extend the support for taskloop to include reduction.

As support for Reduction in taskloop was only added in OpenMP 5.0,
the use of the Clause has been restricted to that version of OpenMP
or greater.
Copy link
Owner Author

Stylie777 commented Nov 5, 2025

@Stylie777 Stylie777 closed this Nov 5, 2025
@Stylie777 Stylie777 deleted the 11-05-_flang_openmp_add_lowering_support_for_taskloop_reductions_ branch November 5, 2025 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment