Re: Add post_expand_call_insn hook

[Tom de Vries <Tom_deVries at mentor dot com>]

On 29-04-14 20:56, Richard Henderson wrote:
> > I've written this concept patch, which tries to address the same problem, but
> > >in a different (and I hope more generic) way.
> > >
> > >It adds a post-emission C-code operand to define_expand.
> > >
> > >As an example of how this could be useful, for the define_expand of call and
> > >call_value in the arm target, I'm using the new operand to do the post-emit
> > >call processing done currently in arm_emit_call_insn. This allows us to
> > >eliminate the call_internal and call_value_internal define_expands, and
> > >simplifies the call and call_value define_expands.
>
> Is this patch really any better?  I can't see that it is myself.  It seems to
> me that the existing mechanism to emit the call, then append to FUNCTION_USAGE
> is perfectly clear.  This new argument to define_expand seems less clear.
>
> What are you trying to fix, anyway?

Richard,

In arm.md, the define_expand "call" rtl template is not used, because DONE is 
used in the preparation statements operand. The DONE is there, because we need a 
handle to the emitted insn to do post-emit processing.

The post-emission C-code operand that this patch introduces provides a handle to 
the emitted insn, which means we no longer need to use an explicit emit and DONE 
to get that handle.  And without that DONE, we can use the rtl template of 
define_expand "call", and no longer need the call_internal.

So we eliminate an define_expand (which is shorter, and removes duplicate code), 
and deal with expansion inside a single define_expand (which is clearer). To me, 
those are the benefits.

I agree the existing mechanism is perfectly clear.

Still I think that a 'finalization statements' operand is as clear as a 
'preparation statements' operand.

Thanks,
- Tom