Re: [RFC] Improve memset expansion on i?86/x86_64

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Thu, Dec 11, 2008 at 4:12 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Dec 11, 2008 at 04:01:41PM +0100, Richard Guenther wrote:
>> > +  if (TREE_CODE (exp) == SAVE_EXPR && !SAVE_EXPR_RESOLVED_P (exp))
>> > +    exp = TREE_OPERAND (exp, 0);
>>
>> This asks for a comment.
>
> Ok, will add it.
>
>> > +int
>> > +get_mem_align_offset (rtx mem, int align)
>> > +{
>> > +  tree expr;
>> > +  unsigned HOST_WIDE_INT offset;
>>
>> can't you use get_pointer_alignment and/or get_object alignment here
>> instead of re-inventing most of its wheels?
>
> Unfortunately not.  I've been using get_object_alignment there when
> working on the patch and testing it on short testcases, unfortunately
> that failed miserably during bootstrap.
> The problem is that COMPONENT_EXPRs in MEM_EXPRs may have NULL
> first operand (<variable>.a.b) and get_inner_reference crashes on it.

Uh.  How awfully ugly of whoever generates that MEM_EXPR ... (can we even
do useful things with that?)

> Even if it didn't crash, say stopped the cycle when expr is NULL_TREE,
> to find the alignment we in that case want to look at DECL_FIELD_CONTEXT
> to get the aggregate's TYPE_ALIGN.

I think using TYPE_ALIGN is fragile given how lazy we are in correctly
propagating
for example packed attributes to pointer types.

> MEM_EXPRs ATM contain only very small subset of trees get_object_alignment
> handles, only DECL_Ps, INDIRECT_REF_Ps and COMPONENT_REFs, where
> COMPONENT_REF can have COMPONENT_REF, DECL_P or NULL first operand.
> So I think it isn't so big deal to not reuse get_object_alignment.

Ok.  Please add a comment to the function mentioning above issues.

Thanks,
Richard.