On Thu, Mar 31, 2011 at 9:14 AM, Paolo Bonzini <[email protected]> wrote:
> On 03/31/2011 03:22 AM, Michael Matz wrote:
>>
>> this came up when looking into why the static ctors contain useless trees
>> (like casts). We can simply canonicalize them while varpool analyzes
>> pending decls. It'll look at initialzers once, where we can "gimplify"
>> them. This requires making canonicalize_constructor_val be able to be
>> called outside of functions. And it requires the java frontend not
>> leaving a dangling function decl as current (for the static ctor function
>> it generates).
>
> canonicalize_constructor_val may be doing useful things on ADDR_EXPR too,
> but you don't call it in that case because you only added your code in the
> default case. You only reach it when the ADDR_EXPR is wrapped in a cast.
>
> Any reason why you didn't add it (possibly wrapped in a loop) _before_ the
> switch statement?
Indeed. This comment needs adjustment, too:
/* We never have the chance to fixup types in global initializers
during gimplification. Do so here. */
if (TREE_TYPE (TREE_TYPE (cval)) != TREE_TYPE (TREE_OPERAND (cval, 0)))
cval = build_fold_addr_expr (TREE_OPERAND (cval, 0));
as we now sort-of do this. In fact it looks like all existing
canonicalize_constructor_val calls are subsumed by the lowering, so,
eventually remove those and move this function to a local place next
to its sole caller.
Richard.
> Paolo
>
