Richard Biener <richard.guent...@gmail.com> writes: >>> The frontend are in charge of specifying the actual argument type and >>> at that point the target may fix the ABI. The ABI can be recorded in >>> the calls fntype, either via its TYPE_ARG_TYPES or in more awkward >>> ways for varargs functions (in full generality that would mean >>> attaching varargs ABI meta to each call). >>> >>> The alternative is to have an actual argument type vector associated >>> with each call. >> >>I think multiple pieces of gimple code would then have to cope with >>that >>as a special case. E.g. if: >> >> void foo (int, ...); >> >> type1 a; >> b = VIEW_CONVERT_EXPR<type2> (a); >> if (a) >> foo (1, a); >> else >> foo (1, b); >> >>gets converted to: >> >> if (a) >> foo (1, a); >> else >> foo (1, a); >> >>on the basis that type1 and type2 are "the same" despite having >>different calling conventions, we have to be sure that the calls >>are not treated as equivalent: >> >> foo (1, a); >> >>Things like IPA clones would also need to handle this specially. >>Anything that generates new calls based on old ones will need >>to copy this information too. >> >>This also sounds like it would be fragile and seems a bit too >>invasive for stage 3. > > But we are already relying on this to work (fntype non-propagation) because > function pointer conversions are dropped on the floor. > > The real change would be introducing (per call) fntype for calls to > unprototyped functions and somehow dealing with varargs.
Hmm, OK. Any suggestions for how the varargs type should be represented? We can't just change (int, ...) to (int, foo, bar), since varargs can be passed differently from non-varargs. We'd need something like "(int, ...) used as (int, foo, bar)" instead. Currently TYPE_ARG_TYPES ends with void_list_node for non-varargs and null for varargs. Perhaps we could instead add a "..." marker, so: <ellipsis_node>: unprototyped function <type1, ellipsis_node>: (type1, ...) prototype <type1, type2>: (type1, type2) prototype <ellipsis_node, type1>: unprototyped function called with type1 <type1, ellipsis_node, type2>: (type1, ...) prototype called with (type1, type2) If so, would something like that be OK during stage3? Richard
