This is the mail archive of the gcc@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: aggregate_value_p in the gimplifier


On Tue, Jul 06, 2004 at 07:24:20PM -0700, Jim Wilson wrote:
> Eric Botcazou wrote:
> >What has changed is that the gimplifier (namely gimplify_modify_expr) 
> >invokes aggregate_value_p on types that the back-end didn't use to see for 
> >the C language.
> 
> This looks a bit questionable to me.  If the gimplifier just wants to 
> know if we have an aggregate type, then it should use AGGREGATE_TYPE_P. 
>  The use of aggregate_value_p here is doing a lot of work for no 
> apparent reason, as it throws away the aggregate_value_p result.

We want to know if we have an aggregate type that is not returned
in registers.  We want this for two reasons:

(1) RESULT_DECLs assigned PARALLEL rtl are only handled in expand_return,
    and not in expand_assignment.  Thus without rearranging things we
    can't separate <RETURN_EXPR <MODIFY_EXPR <RESULT_DECL> value>>.

(2) We don't want to extend the lifetime of return registers.  Which is
    what would happen if we allowed <MODIFY_EXPR <RESULT_DECL> value>
    anywhere in the function.


r~


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