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
