On Tue, 2 Aug 2011, Ira Rosen wrote:
>
> > + /* Now we have matched the statement pattern
> > +
> > + rhs1 = (T1)x;
> > + rhs2 = (T1)y;
> > + op_result = rhs1 OP rhs2;
> > + lhs = (T2)op_result;
>
> Just a note that the patch I proposed for the vectorizer (
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01472.html) also handles
> constants, multiple statements (i.e., op_result doesn't have to be promoted
> itself, but the sequence needs to end up with a promotion), and also it may
> use an intermediate type for OP. The tests in my patch don't match the
> pattern this patch detects.
Ok, I only looked at the description of your patch, not the patch itself.
The patch already handles constant 2nd operands.
It shouldn't be difficult to handle multiple statements here, either by
instead of the above match only
op_result = rhs1 OP rhs2;
lhs = (T2)op_result;
and thus allow iteration on the promoted/demoted operation operands
or by collecting all defs first.
Do you handle arbitrary def trees or only a linear chain as suggested
by
+ S2 x_T = (TYPE) x_t;
+ S3 res0_T = op (x_T, C0);
+ S4 res1_T = op (res0_T, C1);
+ S5 ... = () res1_T; - type demotion
? Thus, do you handle res1_T = op (res0_T, res2_T) with a possibly
different TYPE in its def? The case of
op_result = rhs1 OP CST;
lhs = (T2)op_result;
is probably always profitable to demote to
rhs1' = (T2)rhs1;
lhs = rhs1' OP (T2)CST;
and "iterating" that should be simple (handling two variable
operands will probably get a bit convoluted).
Thanks,
Richard.
