On Wed, 27 Jul 2011, Sebastian Pop wrote:
> On Tue, Jul 26, 2011 at 09:34, Richard Guenther <rguent...@suse.de> wrote:
> > Truncating -1 doesn't matter - it matters that if you perform any
> > unsigned arithmetic in arbitrary precision signed arithmetic that
> > you properly truncate after each operation to simulate unsigned
> > twos-complement wrapping semantic. And if you did that you wouldn't
> > need to sign-extend -1U either.
>
> Ok, so I guess that the type of the expression that we generate from
> Graphite should be, as the original expression, of unsigned type.
> In the previous example,
>
> > for (scat_3=0;scat_3<=4294967295*scat_1+T_51-1;scat_3++) {
> > S6(scat_1,scat_3);
> > }
>
> this is still valid if the type of "4294967295*scat_1" is unsigned.
If 4294967295*scat_1+T_51-1 is always the symbolic number of
iterations then it will be always >= 0, right? I still do not
quite understand where and how "types" enter the picture for
graphite here - if the niter expression was scat_1 + T_51 with
both unsigned then you'd still have to truncate to the result
types precision in case the polyhedral model internally has
infinite precision. So I don't think -1U is in any way special
(it probably just appears more often, and we could avoid some
of the issues with folding the above to T_51 - 1 - scat_1).
> That would fix only -fgraphite-identity: we also have to watch out for
> operations on the polyhedral representation that would use -1U in
> other computations, and here I'm thinking about everything we have
> implemented on the polyhedral representation: dependence test,
> counting the number of points, i.e., all the heuristics, etc.
>
> When disabling Graphite on all unsigned niter expressions, we get
> the following fails:
I think niter expressions are unsigned simply because niter will
always be >= 0. But the issue doesn't seem to be the unsignedness of
niter but the fact that the symbolic expression is computed with
unsigned arithmetic?
> FAIL: gcc.dg/graphite/scop-0.c scan-tree-dump-times graphite "number
> of SCoPs: 1" 1
Where I wonder why we end up with unsigned arithmetic for this
testcase for example. 2 * N + 100 is surely all signed.
[...]
> So the only solution that I can see is to implement the niter analysis
> as the resolution of a constraint system, and that would avoid creating
> the unsigned expressions.
So maybe we can instead try to avoid using unsigned arithmetic
for symbolic niters if the source does not have it unsigned?
Richard.
