On May 3, 2012, at 12:24 , Richard Guenther wrote:
>> One area of potential difference came to mind yesterday: regarding the
>> processing of type alignment differences. VCE to more aligned (of the
>> same size) would make a temp copy to yield a correctly aligned object.
>>
>> Would MEM_REF do that as well ?
>
> A temporary copy?
At least in some cases.
> You mean if I do VIEW_CONVERT_EXPR <double> (longlong)
> on x86 with -malign-double (so long long is 4 byte aligned and double is 8
> byte
> aligned) the access guarantees only 4 byte alignment but if we "spill" that to
> a temporary the temporary will use double as type and thus get larger
> alignment
> of 8 bytes?
Probably not on x86. I am referring to this piece of the RTL expansion:
expand_expr_real_1()
case VIEW_CONVERT_EXPR:
...
/* At this point, OP0 is in the correct mode. If the output type is
such that the operand is known to be aligned, indicate that it is.
Otherwise, we need only be concerned about alignment for non-BLKmode
results. */
if (MEM_P (op0))
...
else if (STRICT_ALIGNMENT
&& mode != BLKmode
&& MEM_ALIGN (op0) < GET_MODE_ALIGNMENT (mode))
{
tree inner_type = TREE_TYPE (treeop0);
HOST_WIDE_INT temp_size
= MAX (int_size_in_bytes (inner_type),
(HOST_WIDE_INT) GET_MODE_SIZE (mode));
rtx new_rtx
= assign_stack_temp_for_type (mode, temp_size, 0, type);
rtx new_with_op0_mode
= adjust_address (new_rtx, GET_MODE (op0), 0);
gcc_assert (!TREE_ADDRESSABLE (exp));
if (GET_MODE (op0) == BLKmode)
emit_block_move (new_with_op0_mode, op0,
GEN_INT (GET_MODE_SIZE (mode)),
(modifier == EXPAND_STACK_PARM
? BLOCK_OP_CALL_PARM : BLOCK_OP_NORMAL));
else
emit_move_insn (new_with_op0_mode, op0);
op0 = new_rtx;
}
Not sure how to trigger this though, and the documentation of
VIEW_CONVERT_EXPR is pretty silent about it :-(
