This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ARM half-precision floating point, 3/8 (target hooks)


Paolo Bonzini wrote:
Okay, the hooks matter is settled. :-)

Thanks for leading me through it.  The comment on double rounding should
be in arm.c, it is not clear otherwise and it would help if at any later
date other targets want to follow the same track.

I've gotten somewhat lost in this discussion. Do I need to make any changes to the hooks, or just add the comment on double rounding?


The rest of the message is about the ABI issue.

A sorry sounds like it would be a good idea [...]
AAPCS defines HFmode parameters and return types to work by converting the values to SFmode, so implementing the AAPCS for such functions (if in
future GCC allows them to be defined) would require calls to the conversion libcalls to be generated as part of the function calling sequence.

And maybe the best thing is to implement it (if not now, just make sure it gets into 4.5). There is already a mechanism to do so, TARGET_PROMOTE_PROTOTYPES.

The best way to do so would be IMO to extend TARGET_PROMOTE_PROTOTYPES
to get a function and a type, and return another type.  Then in the
front-end you apply the function unconditionally like

  if (TREE_CODE (decl) == FUNCTION_DECL)
    {
      struct c_declarator *ce = declarator;

      if (ce->kind == cdk_pointer)
        ce = declarator->declarator;
      if (ce->kind == cdk_function)
        {
          tree args = ce->u.arg_info->parms;
          for (; args; args = TREE_CHAIN (args))
            DECL_ARG_TYPE (args) =
              targetm.calls.promote_prototypes (decl, TREE_TYPE (args));
        }
    }

and likewise in a couple of other places (in one place
default_conversion is called instead, but you can call convert instead
with the result of the hook).

Only ARM and two other targets implement it (SH and SPARC; m32c could
use the default), and the others just use a "stock" function, so
preparing the patch is feasible.

Doing this in the front-end also fixes the problem that...

 care would be needed to
 ensure that whatever compiler-generated function calls it affects, it
 doesn't affect the libcalls converting between HFmode and SFmode

I've gotten lost here, too -- I can't figure out whether the subsequent discussion is endorsing this idea, or not. So, what do I need to do to fix the patch? Add the sorry() calls? Add this hook function? Both? Something else?


-Sandra the confused


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]