Re: target specific builtin expansion (middle end and back end definition inconsistence problem?).

[Feng LI <nemokingdom at gmail dot com>]

Hi Ian,

2012/4/22 Ian Lance Taylor <iant@google.com>:
> Feng LI <nemokingdom@gmail.com> writes:
>
>> Yes, you are right. But how could I reference to a backend defined builtin
>> function in the middle end (I need to generate the builtin function in the
>> middle end and expand it in x86 backend)?
>
> If the function doesn't have a machine-independent definition, then use
> a target hook.

Then I remove the duplicate builtin definition in x86 backend.
I define the builtin function with built_in_class as BUILT_IN_MD in
builtins.def.
So that in the expand_builtin, the target specific hook will be called:
  if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD)
    return targetm.expand_builtin (exp, target, subtarget, mode, ignore);

Then in the middle end I could reference to this builtin function with
tree tcreate_fn = built_in_decls[BUILT_IN_TCREATE], and it'll call
the target specific expansion in the backend.

The problem happens as the code below shows:

builtin_expand (){
    enum built_in_function fcode = DECL_FUNCTION_CODE (fndecl);
}

ix86_expand_builtin{
    enum ix86_builtins fcode = DECL_FUNCTION_CODE (fndecl);
}

The builtin codes (enum built_in_function and ix86_builtins_fcode) are
different sets in
both middle end and backend, so I end up with trapping into this code block:

    if (ix86_builtins_isa[fcode].isa
        && !(ix86_builtins_isa[fcode].isa & ix86_isa_flags))
      {
        char *opts = ix86_target_string (ix86_builtins_isa[fcode].isa, 0, NULL,
                                         NULL, NULL, false);

        if (!opts)
          error ("%qE needs unknown isa option", fndecl);
        else
          {
            gcc_assert (opts != NULL);
            error ("%qE needs isa option %s", fndecl, opts);
            free (opts);
          }
        return const0_rtx;
      }

Not sure if I'm doing it in the right way, help needed...

Thanks,
Feng
>
> (That said I've thought for a while that we need better mechanisms for
> target-specific optimization passes. ?If we had those I would tell you
> to write one. ?E.g., reg-stack.c is a target-specific pass.)
>
> Ian