[PATCH] Relax sizetype constraints in size_binop?

Richard Guenther richard.guenther@gmail.com
Sat Nov 4 11:11:00 GMT 2006

On 11/3/06, Roger Sayle <roger@eyesopen.com> wrote:
> I'd like to solicit opinions on the following innocent looking middle-end
> patch as an alternate solution for PR middle-end/22439.  This issue
> concerns the defensive nature of fold-const.c's size_binop which calls
> abort if ever passed arguments with types other than sizetype and
> bitsizetype, and their signed variants, i.e. it checks for
> As witnessed by PR middle-end/22439 and Richard Henderson's analysis in
> http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00482.html this doesn't
> play well with the philosophy used by the rest of the middle-end,
> especially the gimplifiers, where tree_ssa_useless_type_conversion
> and friends are more lenient provided that the types are in a weaker
> sense equivalent.  This is one of the few places in the compiler where
> we use pointer equality to test for identical types.
> RTH's very reasonable solution to 22439 was to add an explicit check
> for TYPE_IS_SIZETYPE to gimplify_one_sizepos, so that we force the
> preservation of these "special" types.  This follows similar idioms
> used in the front-ends.  For example in C's c-typeck.c:comptypes_internal
> we find the fragment:
>   /* If either type is the internal version of sizetype, return the
>      language version.  */
>       && TYPE_ORIG_SIZE_TYPE (t1))
>     t1 = TYPE_ORIG_SIZE_TYPE (t1);
> and likewise in the C++ code the ominous comment:
>   /* If one is a sizetype, use it so size_binop doesn't blow up.  */
> I'd like to propose an alternate simplifying strategy to this issue.
> It turns out that apart from the strict validity checks, size_binop
> is in fact a shallow wrapper around fold_build2, with some special
> cases for performance.  These underlying functions routinely handle
> expressions with the looser type-system used elsewhere in gimple, and
> the assertion is not for correctness, but to preserve an ancient
> invariant.  Indeed, back prior to tree-ssa, the middle-end had a very
> forgiving (non-existant) type system, so it may have made sense to
> take extra care over the non-front end types the compiler cared about.
> As strange as it may seem, these assertions in size_binop and size_diffop
> are (I believe) the only remaining reason for having special sizetype
> types.  Indeed, the entire tree can be bootstrapped and regression tested
> without failures(*) after completely removing the TYPE_IS_SIZETYPE macro,
> once we allow regular types to be potentially be used to internally
> calculate the sizes of objects.  I believe that LLVM, ORC, LCC and other
> compilers don't internally require separate special types to track object
> size, the way that GCC does.
> Thoughts?

I agree.  But you introduce some new means of (looser) type equality and
feed mismatching types (in the ptr equality sense) to fold.  Was this intended?
If so, can you break out this type-equality predicate to a function?  While
I really like to get rid of TYPE_IS_SIZETYPE, this sneaking in of type
system changes makes me somewhat nervous...

So I'd prefer
  gcc_assert (TREE_TYPE (arg0) == TREE_TYPE (arg1))
which should also work.


More information about the Gcc-patches mailing list