[CIR] Add support for AliasOp

[badumbatish]

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() {}

[bcardosolopes]

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

[bcardosolopes]

This doesn't seem to apply here.

[badumbatish]

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

[bcardosolopes]

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

[badumbatish]

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]

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

[andykaylor]

Will this operation also be used for global variable aliases?

[badumbatish]

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

[badumbatish]

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]

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.