On Mon, 11 May 2020, Alexander Monakov wrote: > On Mon, 11 May 2020, Richard Sandiford wrote: > > > Like you say, the idea is that since the operation is commutative and > > is the same in both vector and scalar form, there's no reason to require > > any -ffast-math flags. > > Note that PR88540 that Richard is referencing uses open-coded x < y ? x : y > (non-commutative) and we want to use SSE minpd even without -ffast-math, as > SSE min/max insns match semantics of open-coded ternary operators. > > (unlike Arm SIMD, SSE does not have a way to compute fmin/fmax with a > single instruction in presence of NaNs)
Indeed. So it looks like for SSE we eventually want phiopt to generate a COND_EXPR here and a new optabs cond_fmin cond_fmax that could be used to vectorize this? cond_fmin and cond_fmax can neither be treated as MIN_EXPR or MAX_EXPR nor fmin/fmax since it is not commutative. The reason why I came back to this is that the x86 backend has define_insns that match the conditional form so RTL if-conversions knows how to generate this but after my patch to add some bit-insert/bit-field-ref combining patterns to GIMPLE RTL if-conversion cannot recoginze them anymore. I'm also pretty sure we do not want cond_fmin/max IFNs on GIMPLE early. That said, I can recover the x86 testcases by just adjusting phiopt here to generate a COND_EXPR (vectorizer ifcvt doesn't handle this case either - which is why it is not vectorized I guess). Not sure if it really fits minmax detection since for sure the "combinations" it does do not apply to the conditional form without extra careful checking (is there any difference between x >= y ? x : y and x > y ? x : y?) Anyway, I need to sit down and more closely look at this. So the x86 part of the patch is clearly bogus and the phiopt part to match the conditional form as IFN_FMIN/MAX as well(?) Richard.
