================
@@ -405,3 +405,45 @@ float fpPostInc2() {
// OGCG: store float %[[A_INC]], ptr %[[A]], align 4
// OGCG: store float %[[A_LOAD]], ptr %[[B]], align 4
// OGCG: %[[B_TO_OUTPUT:.*]] = load float, ptr %[[B]], align 4
+
+_Float16 fp16UPlus(_Float16 f) {
+ return +f;
+}
+
+// CHECK: cir.func @fp16UPlus({{.*}}) -> !cir.f16
+// CHECK: %[[INPUT:.*]] = cir.load %[[F:.*]]
+// CHECK: %[[PROMOTED:.*]] = cir.cast(floating, %[[INPUT]] : !cir.f16),
!cir.float
----------------
bcardosolopes wrote:
> Long term, I think we have at least two options
Both (1) and (2) have different design tradeoffs and my experience has been
that it varies depending on the use case in question. For this specific case,
I'd say that if the promotions aren't crucial for analysis on top of CIR (right
now), I'd defer the details to LLVM, staying with (1) - note that here the
operation itself wraps the semantic, because it contains enough info for you to
lower things properly later on. In case you can see the explicit promotions
being helpful for other things (random speculative example: callconv lowering)
then it might be worth doing (2). Either way, implementation experience will
tell if you should move from one to the other approach over time - in CIR so
far we've come back n forth with some design as part of evolving things over
time.
https://github.com/llvm/llvm-project/pull/133829
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
