[patch, scev] Fix PR tree-optimization/36630

[Ira Rosen]

Hi,

Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote on 28/07/2008 19:49:07:

> Hi,
>
> > In that case, for Ira's original patch, do we need to STRIP_NOPS and
> > then put them back (depending on where the cast is) when we extract
> > the evolution for a given loop?
> > IE won't simply using STRIP_NOPS give wrong answers by eliminatingthe
casts?
>
> using STRIP_NOPS is wrong, as it only checks that the inner and the
> outer type are represented in the same mode; only casts to a narrower
> type or a type of the same precision can be stripped (and the result
> must be casted back to the expected type, i.e. the original type of the
> expression if it is not a pointer type, or to sizetype otherwise).

O.K., thanks for the explanation.

Maybe there is another way to get the step for (short int) {(short unsigned
int) i_44,+, 1}_1)?

>
> Regardless of whether this change to evolution_part_in_loop_num is made,
> to fix PR 36630, vectorizer must be able to deal with the situation that
> evolution_part_in_loop_num returns NULL (the description of the PR
> suggests that either some check must be added to the analysis phase, or
> the transformation phase must be modified to deal with this
> possibility),

O.K., I will try to do that.

Thanks,
Ira

>
> Zdenek
>
> > On Mon, Jul 28, 2008 at 8:21 AM, Zdenek Dvorak <rakdver@kam.mff.
> cuni.cz> wrote:
> > > Hi,
> > >
> > >> > On Thu, Jul 17, 2008 at 4:25 AM, Ira Rosen <IRAR@il.ibm.com>
wrote:
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > The test in PR36630 ICEs, since evolution_part_in_loop_num
> returns NULL
> > >> for
> > >> > > the access function (short int) {(short unsigned int) i_44,+,
1}_1).
> > >> > > Adding STRIP_NOPS before chrec's analysis solves the problem.
> > >> >
> > >> > How did the access function get a cast in front of it in the
> first place?
> > >> >
> > >> > My admittedly possibly out of date recollection is that casts can
only
> > >> > occur inside the chrec.
> > >
> > > no, chrecs may appear anywhere in the expression; in this particular
> > > case, (short int) {(short unsigned int) i_44, +, 1}_1 cannot be
folded
> > > to {(short int) i_44, +, 1}_1, as the former may wrap, but the latter
> > > cannot (assuming no overflow semantics for signed integer
operations).
> > >
> > > Zdenek
> > >