Hi,
On Mon, 16 Dec 2013 17:22:59, Eric Botcazou wrote:
>
>> That sounds less conservative though. Anyway, that was just some thought
>> to fix the eventual fallout of making more types have BLKmode.
>
> In the end I was too optimistic... Testing a revised patch on x86 revealed a
> obscure case where the new BLKmode triggered a layout change (I presume that
> there is some randomness in struct-layout-1.exp because I didn't see it for
> the earlier runs). The culprit is:
>
> int
> x86_field_alignment (tree field, int computed)
> {
> enum machine_mode mode;
> tree type = TREE_TYPE (field);
>
> if (TARGET_64BIT || TARGET_ALIGN_DOUBLE)
> return computed;
> mode = TYPE_MODE (strip_array_types (type));
> if (mode == DFmode || mode == DCmode
> || GET_MODE_CLASS (mode) == MODE_INT
> || GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)
> return MIN (32, computed);
> return computed;
> }
>
> which of course blatantly violates the do-not-rely-on-mode rule. Although the
> layout change apparently occurs very rarely, I think that this rules out the
> direct mode change in stor-layout.c... <snip>
>
> At this point, I'd agree with either of the following 2 solutions:
>
> 1. Instead of changing the mode, we set a flag on the type (conveniently we
> can reuse the TYPE_NO_FORCE_BLK bit since it's only set for types with BLKmode
> already) and test it during RTL expansion to force BLKmode,
>
> 2. Bernd's latest patch, but with the new boolean parameter explicitly called
> KEEP_UNALIGNED_MEMORY and a fat comment along the lines of:
>
> If KEEP_UNALIGNED_MEMORY is true, we don't adjust a returned MEM rtx that
> wouldn't be sufficient aligned for its mode; instead, it's up to the caller
> to deal with it afterwards. This is used to make sure that unaligned base
> objects for which out-of-bounds accesses are supported, for example record
> types with trailing arrays, aren't realigned behind the back of the caller.
> The normal operating mode is to pass FALSE for this parameter.
>
> --
> Eric Botcazou
Thanks for you analysis, Eric.
In the moment I am under the impression, that it is not safe to change
the type-mode at all. The other example with register variables, of struct-type
which were sensitive to the BLKmode, does certainly also mean that the target
is peeking at the mode somewhere, and who knows what's next...
Renaming the parameter is of course an option, and often choosing the right name
helps more than lots of comments, but if I call it KEEP_UNALIGNED_MEMROY
it is not clear, that this parameter is only to be used to expand an inner
reference.
In general I like the comment, and I am open for other suggestions how
to call the parameter.
How about this comment?
"If EXPAND_REFERENCE is true, we are expanding an inner reference.
In this case, we don't adjust a returned MEM rtx that wouldn't be sufficient
aligned for its mode; instead, it's up to the caller to deal with it
afterwards.
This is used to make sure that unaligned base objects for which out-of-bounds
accesses are supported, for example record types with trailing arrays, aren't
realigned behind the back of the caller.
The normal operating mode is to pass FALSE for this parameter."
Bernd.
