On Wed, 25 Sep 2019, Eric Botcazou wrote:
> > For the PR it would be good enough. Though I wonder what the original reason
> > for the mode handling was. Was it to avoid not naturally aligned modes for
> > strict align targets? Or modes for non-mode size entities?
>
> Bit-field extraction ultimately required integer modes before vector modes
> came to light so I think that preserving their original mode was useless.
I see. So I misremember seeing aggregate typed BIT_FIELD_REFs
(that was probably VIEW_CONVERTs then...). Still the GIMPLE verifier
only has
else if (!INTEGRAL_TYPE_P (TREE_TYPE (expr))
&& TYPE_MODE (TREE_TYPE (expr)) != BLKmode
&& maybe_ne (GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE
(expr))),
size))
{
error ("mode size of non-integral result does not "
"match field size of %qs",
code_name);
return true;
}
it doesn't verify that besides integral typed expressions only
vector typed expressions are allowed.
Anyhow - the original patch succeeded bootstrapping and testing.
The way I proposed it:
/* For vector types, with the correct size of access, use the mode
of
inner type. */
if (((TREE_CODE (TREE_TYPE (TREE_OPERAND (exp, 0))) == VECTOR_TYPE
&& TREE_TYPE (exp) == TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp,
0))))
|| !INTEGRAL_TYPE_P (TREE_TYPE (exp)))
&& tree_int_cst_equal (size_tree, TYPE_SIZE (TREE_TYPE (exp))))
mode = TYPE_MODE (TREE_TYPE (exp));
matches in sofar that we only restrict integer types (not modes) and
for integer types allow extracts from vectors (the preexisting
check for a matching component type is a bit too strict I guess).
Thus, OK with adjusting the comment to reflect the change?
Thanks,
Richard.
