On Tue, Aug 30, 2016 at 2:09 PM, Joseph Myers <jos...@codesourcery.com> wrote:
> On Tue, 30 Aug 2016, Uros Bizjak wrote:
>
>> I didn't find a way around this limitation, so I propose to disable
>> _FloatN on alpha with the attached patch.
>
> If your ABI requires binary32 values to be promoted in variable arguments,
> I'd think you could do that with a new target hook that specifies a type
> to promote to in variable arguments (when such promotion otherwise would
> not occur), affecting code generation for both function calls and va_arg
> (but not for unprototyped function calls, only for variable arguments).
> (TS 18661 allows conversion to the same type to act as a convertFormat
> operation, so it's allowed for such argument passing to convert sNaNs to
> qNaNs, which would be the effect of having such conversions to and from
> binary64 in the call path.)
>
> (Ideally of course such a hook would take effect *after* the front end,
> but various existing such hooks operate in the front end so I don't think
> it's a problem for a new hook to do so as well.)
IIUC, trying to solve this issue in the front-end would bring us to
float->double promotion rules for variable arguments. The compiler
doesn't convert va-args automatically, it only warns for undefined
situation, e.g.:
--cut here--
#include <stdarg.h>
float sum (float a, ...)
{
va_list arg;
float acc = a;
va_start (arg, a);
acc += va_arg (arg, float);
va_end (arg);
return acc;
}
--cut here--
$ gcc -O2 va.c
va.c: In function ‘sum’:
va.c:9: warning: ‘float’ is promoted to ‘double’ when passed through ‘...’
va.c:9: warning: (so you should pass ‘double’ not ‘float’ to ‘va_arg’)
va.c:9: note: if this code is reached, the program will abort
In a similar way, if we require that _Float32 gets promoted to
_Float64 in va-arg, all the compiler can do is to generate a
target-dependant warning, so user can fix the program. I don't think
this is desirable, as we would have something like:
#ifdef __alpha__
acc += va_arg (arg, _Float64);
#else
acc += va_arg (arg, _Float32);
#endif
Maybe better way forward would be to introduce a backend hook to
generate target-dependant load of the argument from the save area.
This way, it would be possible to emit some kind of builtin that
expands to some RTX sequence.
Uros.
