On Thu, Nov 21, 2013 at 12:18:45PM +0100, Richard Biener wrote:
> > Bootstrap/regtest pending, ok at least for this for the start and can be
> > improved later on?
>
> Ok, this should catch most of the vectorizer cases.
>
> Zero could also be handled for PLUS_EXPR, likewise one for MULT_EXPR.
> I think for induction it's common to have { base, base + 1, base + 2, ...
Of course I handle base for PLUS_EXPR (i.e. zero addend), what I meant
is that for MULT_EXPR, you can actually not have any base at all for
a subset of the elements, just constant 0, because when you multiply
arbitrary base with 0, you get 0.
> why loop here? Do you want to catch base + 1 + 2? I think that's
> hiding a missed optimization elsewhere for no good reason.
I had that in the patch first, unfortunately it is a pass ordering issue.
stmp_var_.25_67 = x_27 + 3;
stmp_var_.25_68 = stmp_var_.25_67 + 3;
stmp_var_.25_69 = stmp_var_.25_68 + 3;
stmp_var_.25_70 = stmp_var_.25_69 + 3;
stmp_var_.25_71 = stmp_var_.25_70 + 3;
stmp_var_.25_72 = stmp_var_.25_71 + 3;
stmp_var_.25_73 = stmp_var_.25_72 + 3;
vect_cst_.26_74 = {x_27, stmp_var_.25_67, stmp_var_.25_68, stmp_var_.25_69,
stmp_var_.25_70, stmp_var_.25_71, stmp_var_.25_72, stmp_var_.25_73};
is exactly what I see in the last veclower pass, because there is no
forwprop between vect pass and veclower. So, do you want to schedule
another forwprop before veclower? Moving veclower later sounds bad,
we really need the stuff created by veclower cleaned up too.
Jakub
