This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Preserve pointer types in ivopts
- From: Zdenek Dvorak <rakdver at iuuk dot mff dot cuni dot cz>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 15 Mar 2012 23:12:06 +0100
- Subject: Re: Preserve pointer types in ivopts
- References: <4F624077.8040103@codesourcery.com>
Hi,
> Currently, tree-ssa-loop-ivopts assumes that pointers and integers can
> be used interchangeably. It prefers to compute everything in unsigned
> integer types rather than pointer types.
> On a new target that I'm working on, this assumption is problematic;
> casting a pointer to an integer and doing arithmetic on the integer
> would be much too expensive to be useful. I came up with the patch
> below, which makes ivopts try harder to preserve pointer types.
> tree-affine is changed to keep track of base pointers, and do arithmetic
> (in particular subtraction) properly if base pointers are involved.
>
> Bootstrapped and regression tested with all languages on i686-linux. I
> get FAILs in:
>
> * gcc.dg/guality/pr43051-1.c
> A somewhat contrived testcase; gdb now produces "optimized out"
> messages which I think is acceptable? In any case I remain to be
> convinced that this testcase demonstrates any real problem.
> * gcc.dg/tree-ssa/reassoc-19.c scan-tree-dump-times reassoc2 " \+ " 0
> This seems to fail because we do POINTER_PLUS (ptr, NEG offset))
> rather than (char *)((int)ptr - offset). As far as I can tell this
> is also not a real problem, but I don't know how to adjust the
> testcase.
>
> Comments? Ok?
the reason unsigned integer types are prefered is that possible overflows
during the computation have defined semantics. With pointer types, the
intermediate steps of the computations could have undefined behavior, possibly
confusing further optimizations. Is the patch with this regard?
Zdenek