On Thu, 23 Feb 2023 04:53:34 GMT, Martin Doerr <mdo...@openjdk.org> wrote:
> > I will do a more thorough review soon. > > Thanks a lot! > > > > The ABI has some tricky corner cases related to HFA (Homogeneous Float > > > Aggregate). The same argument may need to get passed in both, a FP reg > > > and a GP reg or stack slot (see "no partial DW rule"). This cases are not > > > covered by the existing tests. > > > > > > FWIW, we have to do this for Windows vararg floats as well > > ([here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java#L231-L239)) > > This can be done by `dup`-ing the value, and using 2 `vmStore`s. (each > > `vmStore` corresponding to a single register/stack location). Doing > > something similar might be simpler than the `INTEGER_AND_FLOAT` and > > `STACK_AND_FLOAT` storage types you're using right now. I'm not sure if > > that is related to the other limitations you mention? Might be interesting > > to look into. (perhaps as a separate RFE. I don't have a big issue since > > the current approach stays in PPC-only code) > > Maybe I need to think a bit more about it. I don't really like the extra > cases for `INTEGER_AND_FLOAT` and `STACK_AND_FLOAT`. On the other side, doing > it in the CallArranger would break the design of factoring out the allocation > from the binding generation. In addition, it seems like PPC64 is even more > tricky than the Windows case. I need to pass 2 float arguments in a GP reg > (or stack slot) plus one of these 2 floats in float register F13. I think > this can get implemented more easily in the backend. Do you agree? I think the same arguments apply here. I'll have a more thorough look at the patch and then get back to you on this. ------------- PR: https://git.openjdk.org/jdk/pull/12708
