On 05/22/2018 09:19 AM, Peter Maydell wrote: > But what we actually have is > target/arm/helper.c:float16 HELPER(recpe_f16)(float16 input, void *fpstp) > target/arm/helper.c:float16 HELPER(vfp_sltoh)(uint32_t x, uint32_t > shift, void *fpst) > > (and others that you can find by grepping for "float16 HELPER") -- > the helpers don't return a uint32_t, they return float16. > In fact if you try to make them return uint32_t then you get > a compile error, because the DEF_HELPER_* macros prototype them > as returning float16 when you say the return type is 'f16'.
Grr. That is definitely not what I thought we were wiring up. So, do you think it is sufficiently less confusing for developers within target/* to have "f16" expand to "float16" as opposed to uint32_t? It would be significant surgery within tcg to allow such types to be passed down. Although I've been wondering for some time if we might be able to handle int128_t as a native tcg type, and that would require similar changes. r~
