[CIR] Backport rename ComplexAttr to ConstComplexAttr #1974
Conversation
AmrDeveloper
requested review from
andykaylor,
bcardosolopes,
lanza and
xlauko
as code owners
xlauko
left a comment
xlauko
left a comment
There was a problem hiding this comment.
Why was this change introduced in the upstream in the first place?
From my point of view it is rendundant information on the attribute as it is from the difenition of an attribute a constant. I would expect us going the other way and removevingconst_ from other attributes.
Also then when used as ssa value you already mark it as constant in the operation name. Having cir.const #cir.const_complex with repeated const comes to me as unnecessary.
For instance other arithmetic constants we keep as #cir.int and #cir.fp still.
| return cir::ConstComplexAttr::get(builder.getContext(), complexType, | ||
| cir::IntAttr::get(complexElemTy, real), | ||
| cir::IntAttr::get(complexElemTy, imag)); |
There was a problem hiding this comment.
No need for complexType here as we can infer it in builder?
| cir::FPAttr::get(complexElemTy, imag)); | ||
| const llvm::APFloat &real = Value.getComplexFloatReal(); | ||
| const llvm::APFloat &imag = Value.getComplexFloatImag(); | ||
| return cir::ConstComplexAttr::get(builder.getContext(), complexType, |
There was a problem hiding this comment.
No need for complexType here as we can infer it in builder?
I did that to be consistent with other const for example const_vector, const_record and also there is a case for example globals, it will not have const But for locals, yes it will have unnecessary const, I am okey with removing the const from the name too |
2 participants
Backporting renaming ComplexAttr to ConstComplexAttr from the upstream