[PATCH] Allow FMAs in safe math mode in some cases when one operand of the fmul is either exactly 0.0 or exactly 1.0.

[Hal Finkel]

----- Original Message -----
> >> I ended up making it work on vectors on constrained cases (since
> >> the
> >> vector case was tested for when the function was recursive), but
> >> it
> >> tools a lot of thinking to convince myself I hadn't made a
> >> mistake.
> >>
> >> Do you think the vector case will come up enough to make this
> >> worthwhile? The problem is that the vector has to be transparently
> >> defined in the same basic block as the fmul and fadd for it to
> >> work,
> >> and most I think most vectors will be created using some kind of
> >> control flow that will necessarily span more than one basic block.
> >
> > I'm thinking of something like this: autovectorize this:
> > for (...) {
> >   a[i] = 1.0 + b[i]*c[i];
> > }
> > and you'll get a uniform vector of 1.0. I think that this is not
> > uncommon.
> >
> 
> I would like to be able to handle this case and others like it but
> I'm
> not sure if it will work even if I make DAGCombiner aware of vectors,
> because the DAGCombiner cannot examine basic blocks other than the
> one
> currently being processed. It depends on how the IR passes decide to
> arrange the code. Basically, SelectionDAG has to have enough
> information to prove that a vector is all 0's or 1's just by
> examining
> SDNodes within a single basic block, which I'm not sure will work in
> this case.

I think that this case would work because you would end up looking at the operands of the build_vector node. Doing this in full generality would require some kind of work queue (although we could handle the simple 'splat' case without that).

> 
> In any case, I think that should be a separate patch.

Agreed.

> I'll add more
> checks for the scalar case and update this one first.
> 

Great!

 -Hal

> Thanks,
> Stephen
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory