Not all derived type can be taken as abstract result. The CPTR type
should be treated as return by value so to interoperable with C
functions. Fix the function result rewrite for CPTR type, but it
should be generalized for all derived types. The ABI of
interoperability with C for derived type is architecture dependent,
which should be supported later.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks so much for working on this. Aside from a few comments on function names and grammar in comments, all builds and tests correctly and looks good to me.
I've also verified that this fixes the test case in issue #58772.
@jeanPerier, can you also please take a look at this patch?
flang/lib/Optimizer/Transforms/AbstractResult.cpp | ||
---|---|---|
61–62 | It looks like the function getNewFuncResultType is specific to functions that return CPTR types. If so, I recommend that this be reflected in the name -- perhaps getCptrFuncResultType? Also, I would reword the comment as follows: /// This is for function result types that are of type C_PTR from ISO_C_BINDING. Follow the /// ABI for interoperability with C. | |
109 | "derived type" should read "derived types". | |
192 | "derived type" should read "derived types". | |
325 | "derived type" should read "derived types". |
flang/lib/Optimizer/Transforms/AbstractResult.cpp | ||
---|---|---|
149 | Shouldn't this be callOp.getOperands().begin() +1 to skip the function address that was already added above ? | |
flang/test/Fir/abstract-results.fir | ||
90 | Why not using fir.ref<None> so that it is sure the ABI matches what is done for a void* return type in C ? |
flang/lib/Optimizer/Transforms/AbstractResult.cpp | ||
---|---|---|
149 | Did you comment this when you read the last update? I think this has been updated. | |
flang/test/Fir/abstract-results.fir | ||
90 | The test case happened to return a C pointer. It does seem to be more reasonable to return fir.ref<None> for a c_ptr. However, for general purpose of ABI of returning a derived type with only one component with the type i64, the ABI for the derived type returned is i64. Finally, there will be no isa_builtin_cptr_type check for c_ptr. Instead, it will be replaced with checking the derived type. At that time, we need to i64 for c_ptr return value. |
Thanks for the quick fix!
All builds and tests correctly and looks good to me. I've also verified that this fixes issue #58849.
Please wait for @jeanPerier to approve before merging.
flang/lib/Optimizer/Transforms/AbstractResult.cpp | ||
---|---|---|
149 | Yes, looks good now. | |
flang/test/Fir/abstract-results.fir | ||
90 | Let's discuss this outside of this change. I feel C_PTR is special enough so that we should not treat it as a struct {i64} in function interface. I just feel using fir.ref<None> will ensure it is OK regardless of the ABI (it is likely i64 works with most, but it would just be simpler to use fir.ref<None> than to verify this assumption for every ABI). Then, I am not entirely clear where you are going with the next change extending this to single component derived types. Is this only in the BIND(C) context or for all functions ? For BIND(C), I agree we may have to go down that rabbit hole, and it won't be fun to replicate the C ABI generated by clang for structs, that I guess is likely target dependent. |
It looks like the function getNewFuncResultType is specific to functions that return CPTR types. If so, I recommend that this be reflected in the name -- perhaps getCptrFuncResultType?
Also, I would reword the comment as follows: