[CIR] Add support for AliasOp #1925

badumbatish · 2025-09-29T20:42:00Z

Related to #1913.

Added alias op and verifier for call op. Failing two tests related to constructor and destructor aliases

Clang :: CIR/CodeGen/ctor-alias.cpp
Clang :: CIR/CodeGen/virtual-destructor-calls.cpp

Right now cir::FuncOp CIRGenModule::GetOrCreateCIRFunction is being used in a lot of place where if we switch to using Alias in emitAliasForGlobal, we'll hit cast type error. I'm not quite sure if i should change the function result type to be mlir::Operation* or something that encompasses both function and alias or not

Pilot test case

class A {
public:
  A();
} A;
A::A() {}

Closes llvm#1367 --------- Co-authored-by: Sirui Mu <msrlancern@gmail.com> Co-authored-by: Amr Hesham <amr96@programmer.net> Co-authored-by: Chibuoyim (Wilson) Ogbonna <ogbonnachibuoyim12@gmail.com> Co-authored-by: Yue Huang <30948580+AdUhTkJm@users.noreply.github.com> Co-authored-by: Morris Hafner <mmha@users.noreply.github.com> Co-authored-by: Morris Hafner <mhafner@nvidia.com> Co-authored-by: Sharp-Edged <48861530+Sharp-Edged@users.noreply.github.com> Co-authored-by: Bruno Cardoso Lopes <bruno.cardoso@gmail.com> Co-authored-by: Letu Ren <fantasquex@gmail.com>

…#1521) - Part of llvm#70 This is not very useful now, as both branches of interest are NYI. I will try to implement the real features in subsequent patches.

…ity and maintainability (llvm#1525) As noted in [this comment](llvm#1442 (comment)), the nested if-arms in `GlobalOpLowering` are somewhat confusing and error-prone. This PR simplifies the logic into more straightforward components. Since LLVM's GlobalOp accepts two types of initializers (either an initializer value or an initializer region), we've extracted the decision logic into a separate function called `lowerInitializer`. This function takes two inout arguments: `mlir::Attribute &init` (for the attribute value) and `bool useInitializerRegion` (as the decision indicator). All code paths then converge at a common epilogue that handles the operation rewriting. The previous implementation for lowering `DataMemberAttr` initializers relied on recursion between MLIR rewrite calls, which made the control flow somewhat opaque. The new version makes this explicit by using a clear self-recursive pattern within `lowerInitializer`.

Fix llvm#1371. Not sure about whether we could remove `convertTypeForMem` completely. Let's fix the doc first.

This change moves all declarations of emit* functions in CIRGenFunction.h into a common location and sorts them alphabetically. The goal of this change is to make it easier to keep upstream and incubator code in a consistent location, making functions easier to find for upstreaming and minimizing conflicts in the incubator when rebasing. I did most of this sort manually, and I've probably been inconsistent in how I treat sorting of uppercase versus lowercase. I made no attempt to provide a rule for ordering different declarations of functions with the same name. We can improve on that over time if anyone feels the need. I tried very hard not to drop comments (one of the reasons I had to do this manually), but I may have lost a few. This change loses the grouping of some declarations that were co-located by common purpose, but most of the declarations lacked a coherent ordering, so I think this is a step forward overall.

This is a rebased version of the inactive PR llvm#1380. --------- Co-authored-by: koparasy <parasyris1@llnl.gov>

Adds implementation for ATanOp's lowering ThroughMLIR.

Lower `vabds_f32` and `vabdd_f64`

Adds implementation for ACosOp's lowering ThroughMLIR.

Lower vmaxv_s32

Adds implementation for ASinOp's lowering ThroughMLIR.

Lower vmaxv_u32

Lower vmaxvq_f64

- Part of llvm#70.

Lower vmaxnmvq f32 and f64

In the review for upstreaming unary operation support (llvm/llvm-project#131369), it was suggested that the VisitPlus and VisitMinus functions should be combined. This is a backport of that refactoring.

This also removes some unused `#include`s. I choose to allow lowering to LLVM dialect when we're lowering CIR to MLIR core dialects, because some operations don't have their counterparts in these dialects (for example, `UnreachableOp -> llvm.unreachable` and `LLVMIntrinsicCallOp -> cir.llvm.intr.xxx`). I don't think we can delay them to the MLIR->LLVM pass as it seems we assume all CIR operations have been lowered after CIR->MLIR conversion. Co-authored-by: Yue Huang <yh548@cam.ac.uk>

…llvm#1543) - Part of llvm#1192

Lower vmaxnmv_f32

Update getZeroInitAttr to cover more FP types, Backport from (llvm/llvm-project#133100)

Adds implementation for TanOp's lowering via ThroughMLIR.

Upstream commit changed behavior llvm/llvm-project@ff585fe I tested in original clang and it produced the same IR with clangir. Related: llvm#1497

…nmvq_f32 (llvm#1546) ower vminnmv_f32, vminnmvq_f64 and vminnmvq_f32

…llvm#1547) When a pointer variable is initialized with a null pointer, the AST contains a NullToPointer cast. If we just emit a null pointer of the correct type, we will miss any side effects that occur in the initializer. This change adds code to emit the initializer expression if it is not a simple constant. This results in an extra null pointer constant being emitted when the expression has side effects, but the constant emitted while visiting the expression does not have the correct type, so the alternative would be to capture the emitted constant and bitcast it to the correct type. An extra constant seems less intrusive than an unnecessary bitcast.

Lower vminv_s32

Lower vminv_u32

llvm#1552) These entries exist in OG but are not present in CIR codegen.

Added: - `cos` - `floor` - `round` - `rint` - `nearbyint` - `sin` - `sqrt` - `tan` - `trunc`

@bar

Failure: ``` calling convention does not permit calls call spir_kernel void @bar(ptr addrspace(1) %10) fatal error: error in backend: Lowering from LLVMIR dialect to llvm IR failed! ```

…urn}

This makes it on par with OG but does not add anything just yet (same NYI asserts should fail).

This will enable handling for records (coming next)

bcardosolopes

Thanks for the PR, besides comments, this also needs testcases and LLVM lowering support.

clang/lib/CIR/CodeGen/CIRGenModule.cpp

bcardosolopes · 2025-09-29T23:04:25Z

clang/lib/CIR/CodeGen/CIRGenModule.cpp

+    mlir::OpBuilder::InsertionGuard guard(builder);
+
+    // Some global emissions are triggered while emitting a function, e.g.
+    // void s() { x.method() }


This doesn't seem to apply here.

i think i need some help and explanation on this comment in the OG createCIRFunction to understand more why it's not applicable.

bcardosolopes · 2025-09-29T23:05:43Z

clang/lib/CIR/CodeGen/CIRGenModule.cpp

+    // Be sure to insert a new function before a current one.
+    auto *curCGF = getCurrCIRGenFun();
+    if (curCGF)
+      builder.setInsertionPoint(curCGF->CurFn);


is this ever the case? I can't see how one might want to insert an alias op outside the module level scope

i'm not quite sure what you mean here? don't we want to reset the insertion point if we're inside a function?

bcardosolopes · 2025-09-29T23:07:05Z

clang/include/clang/CIR/Dialect/IR/CIROps.td

 >;

+def CIR_AliasOp : CIR_Op<"alias", [AutomaticAllocationScope, CallableOpInterface,
+                       FunctionOpInterface, IsolatedFromAbove]> {


You need to add a description, examples, etc, see others for inspiration

clang/lib/CIR/Dialect/IR/CIRDialect.cpp

clang/include/clang/CIR/Dialect/IR/CIROps.td

andykaylor · 2025-09-29T23:53:48Z

clang/include/clang/CIR/Dialect/IR/CIROps.td

+    /// Returns the region on the current operation that is callable. This may
+    /// return null in the case of an external callable object, e.g. an external
+    /// function.
+    ::mlir::Region *getCallableRegion() {


Will this operation also be used for global variable aliases?

hi Andy, I want to have a simple lowering to LLVM_AliasOp but not sure how messy if the same op has two different functionalities. I want to try using 1 op first. I can change the comments

clang/lib/CIR/CodeGen/CIRGenModule.cpp

badumbatish · 2025-10-01T23:26:47Z

This looks a bit odd. Looks like both fn and alias implement the came callable interfaces, so why not refactor this in terms of the needed interface?

I've refactored the code to use CIRCallableOpInterface instead of FuncOp now but was wondering if it is ergonomic to do so. Right now if some person wants to use some methods that exists in FunctionOpInterface, they need to search up the return type and the argument type and add it to the CIRCallableOpInterface first, if they dont want to cast it to FunctionOpInterface. It stinks a bit but on top of my mind i can't see another cleaner way to do this.

Only test case that doesn't pass is the test case that both requires alias as well as lowering to llvm. will handle that soon

bcardosolopes · 2025-10-03T18:22:47Z

This is changing too much, and became way harder to review. What I was trying to suggest is that we shouldn't be duplicating code that can be covered with interfaces, meaning that if you are free to create a new one if it makes more sense, I'm basically alluding to the existing ones, it doesn't mean they have to be used.

In LLVM, there are two cases for alias, function aliases and global aliases. I suggest you start a new PR looking at C/C++ examples that create aliases for both globals and function, and find out via that what it's the abstraction you really need. Right now, as you noticed, we have clunky support for alias functions in CIR, because LLVM dialect didn't have AliasOp until I added it some months ago, so you'd need to think about the design here.

el-ev and others added 30 commits August 10, 2025 19:42

[CIR][CodeGen] Add support for x86 memory fence (llvm#1519)

1b2084e

[CIR][CIRGen][NFC] Handle PragmaComment in emitTopLevelDecl (llvm…

632cd5b

…#1521) - Part of llvm#70 This is not very useful now, as both branches of interest are NYI. I will try to implement the real features in subsequent patches.

[CIR][NFC] Rectify the documentation of convertTypeForMem (llvm#1526)

bd996e1

Fix llvm#1371. Not sure about whether we could remove `convertTypeForMem` completely. Let's fix the doc first.

[CIR][CIRGen][CUDA][NFC] Mirror CUDARuntime skeleton of OG (llvm#1527)

195b9f3

This is a rebased version of the inactive PR llvm#1380. --------- Co-authored-by: koparasy <parasyris1@llnl.gov>

[CIR][CodeGen] Support for BI__rdtsc (llvm#1523)

8114fd3

[CIR][ThroughMLIR] Add ATanOp Lowering (llvm#1528)

93384d6

Adds implementation for ATanOp's lowering ThroughMLIR.

[CIR][CIRGen][Builtin][Neon] Lower vabds_f32 and vabdd_f64 (llvm#1531)

f308d79

Lower `vabds_f32` and `vabdd_f64`

[CIR][ThroughMLIR] Add ACosOp Lowering (llvm#1529)

5dad579

Adds implementation for ACosOp's lowering ThroughMLIR.

[CIR][CIRGen][Builtin][Neon] Lower vmaxv_s32 (llvm#1533)

8715197

Lower vmaxv_s32

[CIR][ThroughMLIR] Add ASinOp Lowering (llvm#1530)

f769f13

Adds implementation for ASinOp's lowering ThroughMLIR.

[CIR][CIRGen][Builtin][Neon] Lower vmaxv_u32 (llvm#1534)

44eeb5b

Lower vmaxv_u32

[CIR][CIRGen][Builtin][Neon] Lower vmaxvq_f64 (llvm#1535)

09639a2

Lower vmaxvq_f64

[CIR][LowerToLLVM] Support for LinkerOptions lowering (llvm#1532)

6ebb491

- Part of llvm#70.

[CIR][CIRGen][Builtin][Neon] Lower vmaxnmvq f32 and f64 (llvm#1537)

cecdb74

Lower vmaxnmvq f32 and f64

[CIR][NFC] Backport refactoring of unary plus/minus handling (llvm#1499)

6f3eeb8

In the review for upstreaming unary operation support (llvm/llvm-project#131369), it was suggested that the VisitPlus and VisitMinus functions should be combined. This is a backport of that refactoring.

[CIR][CIRGen][Builtin] Add __builtin_elementwise_{log, log2, log10} (…

4c0d185

…llvm#1543) - Part of llvm#1192

[CIR][CIRGen][Builtin][Neon] Lower vmaxnmv_f32 (llvm#1544)

d99ee7c

Lower vmaxnmv_f32

[CIR] Backport support zero init attr for all FP types (llvm#1536)

f024937

Update getZeroInitAttr to cover more FP types, Backport from (llvm/llvm-project#133100)

[CIR][ThroughMLIR] Add TanOp Lowering (llvm#1540)

edc35e4

Adds implementation for TanOp's lowering via ThroughMLIR.

[CIR] Unxfail memory effect attribute test (llvm#1545)

d143b14

Upstream commit changed behavior llvm/llvm-project@ff585fe I tested in original clang and it produced the same IR with clangir. Related: llvm#1497

[CIR][CIRGen][Builtin][Neon] Lower vminnmv_f32, vminnmvq_f64 and vmin…

5fe12a3

…nmvq_f32 (llvm#1546) ower vminnmv_f32, vminnmvq_f64 and vminnmvq_f32

[CIR][CIRGen][Builtin][Neon] Lower vminv_s32 (llvm#1550)

eb2e683

Lower vminv_s32

[CIR][CIRGen][Builtin][Neon] Lower vminv_u32 (llvm#1551)

22e9697

Lower vminv_u32

[CIR][CIRGen][Builtin] Add skeleton for missing builtin entries. (NFC) (

a4f40e5

llvm#1552) These entries exist in OG but are not present in CIR codegen.

[CIR][CIRGen][Builtin] Add several elementwise FP builtins (llvm#1553)

eda09e7

Added: - `cos` - `floor` - `round` - `rint` - `nearbyint` - `sin` - `sqrt` - `tan` - `trunc`

bcardosolopes and others added 16 commits August 13, 2025 17:18

[CIR] Fix v8.5a-neon-frint3264-intrinsic.c and remove XFAIL

34f8c17

[CIR] Fix CUDA tests and comment some unsupported bits

69f2099

[CIR] Relax spir-calling-conv.cl in face of lowering error

11e643e

Failure: ``` calling convention does not permit calls call spir_kernel void @bar(ptr addrspace(1) %10) fatal error: error in backend: Lowering from LLVMIR dialect to llvm IR failed! ```

[CIR] Relax openMP taskwait test - some new CIRGen bit missing

86aa3e5

[CIR] Update call lowering tests and remove more XFAILs

80d52d7

[CIR] Fix CIR/IR/invalid.cir and remove XFAIL

fff5b8d

[CIR] Remove XFAIL and add new tests for unreachable_after_{break,ret…

e37e2c9

…urn}

[CIR] CIR/CodeGen/sourcelocation.cpp now passes, remove XFAIL

fe79950

[CIR] Update and UnXFAIL CIR/CodeGen/cast.c

01e18ef

[CIR] Update and UnXFAIL clang/test/CIR/CodeGen/stmt-expr.c

5c17a90

[CIR] Update and UnXFAIL clang/test/CIR/CodeGen/compound-literal.c

26c4b1e

[CIR] Update and UnXFAIL clang/test/CIR/CodeGen/abstract-cond.c

7c21024

[CIR][NFC] Move helper around for upcoming usage

e97724e

[CIR][NFC] Add helpers to improve emitNullConstant

445bb50

This makes it on par with OG but does not add anything just yet (same NYI asserts should fail).

[CIR][NFC] Decompose emitNullConstant into a attribute version

b626e81

This will enable handling for records (coming next)

Pilot for alias op

0030867

badumbatish requested review from andykaylor, bcardosolopes, lanza and xlauko as code owners September 29, 2025 20:42

bcardosolopes reviewed Sep 29, 2025

View reviewed changes

andykaylor reviewed Sep 30, 2025

View reviewed changes

badumbatish added 3 commits September 30, 2025 18:00

Introduce CIRCallableOpInterface

244875d

Resolve general PR comments

0fffc4f

Migrate from func op to CIRCallableOp in function signature

69e415b

lanza force-pushed the main branch 2 times, most recently from 8acaf96 to 58135ea Compare October 20, 2025 17:19

lanza force-pushed the main branch from d9e0f95 to d1b9c55 Compare November 14, 2025 23:21

[CIR] Add support for AliasOp #1925

Are you sure you want to change the base?

[CIR] Add support for AliasOp #1925

Conversation

badumbatish commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bcardosolopes left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bcardosolopes Sep 29, 2025

Choose a reason for hiding this comment

Uh oh!

badumbatish Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

bcardosolopes Sep 29, 2025

Choose a reason for hiding this comment

Uh oh!

badumbatish Oct 1, 2025

Choose a reason for hiding this comment

Uh oh!

bcardosolopes Sep 29, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

andykaylor Sep 29, 2025

Choose a reason for hiding this comment

Uh oh!

badumbatish Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

badumbatish commented Oct 1, 2025

Uh oh!

bcardosolopes commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

28 participants

badumbatish commented Sep 29, 2025 •

edited

Loading

badumbatish Oct 1, 2025 •

edited

Loading

bcardosolopes commented Oct 3, 2025 •

edited

Loading