Re: PATCH: CALL_EXPR representation part 3/9 (middle-end stuff)

[Diego Novillo <dnovillo at redhat dot com>]

Sandra Loosemore wrote on 02/12/07 14:20:

> It's certainly a known issue.  We've tried to convert all the cases where a list 
> was being consed up and then passed directly to build_function_call_expr, but 
> there are a few leftovers like this one where the list is coming from somewhere 
> else, and it would require nonlocal code restructuring to change.  Again, better 
> to deal with this independently of the main megapatch, and try to prioritize it 
> with respect to other remaining cleanups so that we go for the things that have 
> the most bang for the buck first, in terms of avoiding the overhead of 
> constructing temporary argument lists.
OK, sounds reasonable.

> See my response to your previous suggestion along these lines; I don't 
> understand why you think skipping the first operand is the Right Thing To Do.
Yes, I managed to confuse myself there.  Never mind me.

> No, the deleted comments refer to the fact that in the old representation, there 
> had to be special logic in phi_translate to deal with the fact that one of the 
> operands contained a TREE_LIST rather than the argument expressions directly. 
> In the new representation, there is no "argument list" in the CALL_EXPR, either 
> to be extracted and value-numbered or copied as a whole.
Ah, OK.

> > > Index: gcc/tree-ssa.c
> > > ===================================================================
> > > *** gcc/tree-ssa.c    (revision 121705)
> > > --- gcc/tree-ssa.c    (working copy)
> > > *************** tree_ssa_useless_type_conversion (tree e
> > > *** 955,962 ****
> > >         || TREE_CODE (expr) == VIEW_CONVERT_EXPR
> > >         || TREE_CODE (expr) == NON_LVALUE_EXPR)
> > >       return tree_ssa_useless_type_conversion_1 (TREE_TYPE (expr),
> > > !                            TREE_TYPE (TREE_OPERAND (expr,
> > > !                                     0)));
> > >         return false;
> > > --- 955,962 ----
> > >         || TREE_CODE (expr) == VIEW_CONVERT_EXPR
> > >         || TREE_CODE (expr) == NON_LVALUE_EXPR)
> > >       return tree_ssa_useless_type_conversion_1 (TREE_TYPE (expr),
> > > !                            GENERIC_TREE_TYPE (TREE_OPERAND (expr,
> > > !                                         0)));
> > >   
> > Why GENERIC_TREE_TYPE here?  You shouldn't be getting a gimple-stmt here.
>
> Maybe I shouldn't be getting one, but in fact I *did* run into an ICE on this 
> when I was testing this last week.  :-)  IIRC, it happened when making 
> java/lang/reflect/.libs/natMethod.o.
Something's not right.  This should only trigger for expression codes 
that should have a valid TREE_TYPE, so that TREE_OPERAND (expr, 0) 
should most definitely have a non-NULL type.  You may be papering over 
some bug here.