[PATCH] fix PR46029: reimplement if conversion of loads and stores [2nd submitted version of patch]

Abe abe_skolnik@yahoo.com
Thu Jul 2 20:18:00 GMT 2015


On 7/2/15 4:49 AM, Alan Lawrence wrote:

> Thanks, Abe.

You are welcome, sir!  :-)


> As before, I'm still confused here. This still returns false, i.e. bails out of
> if-conversion, if the statement could trap. Doesn't the scratchpad let us handle
> that? Or do we just not care because it won't be vectorizable anyway???

This seems like an opportunity for more optimization in the future.  However, at this time we do not see what kind of code would benefit from this optimization.
If you have some time to spare and wish to spend some of it on this issue, then please find/write a test case that would exercise this path, i.e. a snippet of code
that is not optimized due to the above concern, even though it _could_ be if-converted -- and, preferably, the resulting conversion _is_ vectorizer-friendly.

Of course, even if a test case can be written to trigger this missed opportunity,
that in and of itself does not yet tell us how much opportunity we are missing in _real-world_ code.


> Nit: as before [...]

Thanks for the reminder[s].


> Nit: as before - thanks for fixing the example here

You are welcome.


> Where can I find info on what the different flag values mean?
 > (I had thought they were booleans [...]

Sorry; I don`t know if that is documented anywhere yet.

In this case, (-1) simply means "defaulted": on if the vectorizer is on, and off if it is off.
(0) means "user specified no if conversion" and (1) means "user specified [yes] if conversion".

Regards,

Abe



More information about the Gcc-patches mailing list