Re: [PATCH] Alignment fault during function call

[Bernd Schmidt <bernds at codesourcery dot com>]

On 08/05/2010 06:22 PM, Richard Guenther wrote:
> On Thu, Aug 5, 2010 at 6:20 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> On 08/05/2010 05:59 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 5 Aug 2010, Bernd Schmidt wrote:
>>>
>>>> +  /* Avoid nesting calls.  We allow a few things which we're certain won't
>>>> +     generate library calls.  */
>>>> +  if (is_gimple_call (use_stmt)
>>>> +      && gimple_assign_rhs_code (stmt) != VAR_DECL
>>>> +      && gimple_assign_rhs_code (stmt) != PARM_DECL)
>>>> +    return false;
>>>
>>> You want to allow SSA_NAMEs at least here.
>>
>> Well, if the SSA_NAME was set in a division for example, won't that lead
>> to a libfunc to __div<mode>3?  I saw a case like that in testing.
> 
> Sure.  But see cfgexpand.c where the TERing is important to get
> alignment right.
> 
>       /* TER addresses into arguments of builtin functions so we have a
>          chance to infer more correct alignment information.  See PR39954.  */
>       if (builtin_p
>           && TREE_CODE (arg) == SSA_NAME
>           && (def = get_gimple_for_ssa_name (arg))
>           && gimple_assign_rhs_code (def) == ADDR_EXPR)
>         arg = gimple_assign_rhs1 (def);

Ok.  I guess that means we need the propagation in some cases, but if we
want to be able to eliminate code in calls.c, we must avoid all cases
where it can cause a library call while expanding an argument.

Would this cover the case you're thinking about?

+  if (is_gimple_call (use_stmt)
+      && gimple_assign_rhs_code (stmt) != ADDR_EXPR
+      && gimple_assign_rhs_code (stmt) != VAR_DECL
+      && gimple_assign_rhs_code (stmt) != PARM_DECL)
+    return false;

Any other exceptions we can safely make?


Bernd