-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[CIR] Upstream global initialization for ComplexType #141369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
0e67bfe
70d2be9
8d8485b
b7b9cb4
b959c00
fb3a306
9edaad4
8d4217e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -161,6 +161,54 @@ def CIR_LongDouble : CIR_FloatType<"LongDouble", "long_double"> { | |
}]; | ||
} | ||
|
||
//===----------------------------------------------------------------------===// | ||
// ComplexType | ||
//===----------------------------------------------------------------------===// | ||
|
||
def CIR_ComplexType : CIR_Type<"Complex", "complex", | ||
[DeclareTypeInterfaceMethods<DataLayoutTypeInterface>]> { | ||
|
||
let summary = "CIR complex type"; | ||
let description = [{ | ||
CIR type that represents a C complex number. `cir.complex` models the C type | ||
`T _Complex`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A comment here mentioning how this relates to std::complex would be useful. Note that the representation of std::complex depends on the header file and I believe can even vary depending on which preprocessor symbols are defined (which maybe depends on the target). I don't want a comprehensive explanation of all possibilities here, just a general note explaining that this doesn't directly map to std::complex. I'm not sure what guarantees the C++ standard makes about the implementation of std::complex, but it would be very nice if we could in some way indicate when std::complex is being used. It looks like std::complex is generally unsupported in the incubator, so there's some work to be done to figure that out, I think. |
||
|
||
The type models complex values, per C99 6.2.5p11. It supports the C99 | ||
complex float types as well as the GCC integer complex extensions. | ||
|
||
The parameter `elementType` gives the type of the real and imaginary part of | ||
the complex number. `elementType` must be either a CIR integer type or a CIR | ||
floating-point type. | ||
bcardosolopes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
```mlir | ||
!cir.complex<!s32i> | ||
!cir.complex<!cir.float> | ||
``` | ||
}]; | ||
|
||
let parameters = (ins CIR_AnyIntOrFloatType:$elementType); | ||
|
||
let builders = [ | ||
TypeBuilderWithInferredContext<(ins "mlir::Type":$elementType), [{ | ||
return $_get(elementType.getContext(), elementType); | ||
}]>, | ||
]; | ||
|
||
let assemblyFormat = [{ | ||
`<` $elementType `>` | ||
}]; | ||
|
||
let extraClassDeclaration = [{ | ||
bool isFloatingPointComplex() const { | ||
return isAnyFloatingPointType(getElementType()); | ||
} | ||
|
||
bool isIntegerComplex() const { | ||
return mlir::isa<cir::IntType>(getElementType()); | ||
} | ||
}]; | ||
} | ||
|
||
//===----------------------------------------------------------------------===// | ||
// PointerType | ||
//===----------------------------------------------------------------------===// | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -577,12 +577,33 @@ mlir::Attribute ConstantEmitter::tryEmitPrivate(const APValue &value, | |
case APValue::Union: | ||
cgm.errorNYI("ConstExprEmitter::tryEmitPrivate struct or union"); | ||
return {}; | ||
case APValue::FixedPoint: | ||
case APValue::ComplexInt: | ||
case APValue::ComplexFloat: | ||
case APValue::ComplexFloat: { | ||
mlir::Type desiredType = cgm.convertType(destType); | ||
cir::ComplexType complexType = | ||
mlir::dyn_cast<cir::ComplexType>(desiredType); | ||
|
||
mlir::Type complexElemTy = complexType.getElementType(); | ||
if (isa<cir::IntType>(complexElemTy)) { | ||
llvm::APSInt real = value.getComplexIntReal(); | ||
llvm::APSInt imag = value.getComplexIntImag(); | ||
return builder.getAttr<cir::ConstComplexAttr>( | ||
complexType, builder.getAttr<cir::IntAttr>(complexElemTy, real), | ||
builder.getAttr<cir::IntAttr>(complexElemTy, imag)); | ||
} | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should you assert There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I think |
||
assert(isa<cir::CIRFPTypeInterface>(complexElemTy) && | ||
"expected floating-point type"); | ||
llvm::APFloat real = value.getComplexFloatReal(); | ||
llvm::APFloat imag = value.getComplexFloatImag(); | ||
return builder.getAttr<cir::ConstComplexAttr>( | ||
complexType, builder.getAttr<cir::FPAttr>(complexElemTy, real), | ||
builder.getAttr<cir::FPAttr>(complexElemTy, imag)); | ||
} | ||
case APValue::FixedPoint: | ||
case APValue::AddrLabelDiff: | ||
cgm.errorNYI("ConstExprEmitter::tryEmitPrivate fixed point, complex int, " | ||
"complex float, addr label diff"); | ||
cgm.errorNYI( | ||
"ConstExprEmitter::tryEmitPrivate fixed point, addr label diff"); | ||
return {}; | ||
} | ||
llvm_unreachable("Unknown APValue kind"); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we create a predicate that will verify the IntAttr or FPAttr requirement? I don't think this is sufficient as it is, right?