================
@@ -653,13 +631,13 @@ def CIR_AllocaOp : CIR_Op<"alloca", [
}];
let assemblyFormat = [{
- $allocaType `,` qualified(type($addr)) `,`
+ $name
+ `align` `(` $alignment `)`
+ oilist( `init` $init
+ | `const` $constant
+ | `cleanup_dest_slot` $cleanup_dest_slot)
($dynAllocSize^ `:` type($dynAllocSize) `,`)?
- `[` $name
- (`,` `init` $init^)?
- (`,` `const` $constant^)?
- (`,` `cleanup_dest_slot` $cleanup_dest_slot^)?
- `]`
+ $allocaType `->` qualified(type($addr))
----------------
Andres-Salamanca wrote:
I explored this a bit more and found that `InferTypeOpInterface` could be used
here. One advantage is that callers would no longer need to explicitly
construct the pointer type. For example, instead of:
```cpp
mlir::Type itrTy = cgf.cgm.convertType(cgf.getContext().UnsignedLongLongTy);
auto itrPtrTy = cir::PointerType::get(itrTy);
cir::AllocaOp::create(builder, loc, itrPtrTy, itrTy, "itr", itrAlign);
```
we could just pass the allocated type and let the result type be inferred.
That said, it doesn't actually address the storage redundancy you mentioned.
Even with `inferReturnTypes` building `cir::PointerType::get(ctx,
adaptor.getAllocaType())`, both the allocated type and the pointer result type
still end up stored in the operation.
I also noticed that `llvm.alloca` follows the same approach and stores both
`elem_type` and the pointer result type separately.
Following your suggestion, the format would look something like:
`%0 = cir.alloca "n" align(4) init -> !cir.ptr<!s32i>`
and for dynamic allocations:
`%0 = cir.alloca "n" align(4) init %sz : !u64i -> !cir.ptr<!s32i>`
Does that look good to you?😊
https://github.com/llvm/llvm-project/pull/198962
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
