[PATCH] Retain TYPE_MODE more often for BIT_FIELD_REFs in get_inner_referece

Richard Biener rguenther@suse.de
Thu Sep 26 06:37:00 GMT 2019


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.



More information about the Gcc-patches mailing list