Grant

Agreed. I was only asking for it as one rounding mode of many. And I was kicking myself, afterwards, for seeking a new source of unpredictability in modern hardware. I’ve done enough with ocaps, testing and 3D to know better.

I’m sorry that LLVM is frustrating your team so much. I’d be happy to try to help with that, on my own time, but the logistics are probably too messy. (I’ve got language designitis, too, with a few languages under my belt.)

I was actually thinking of manual vectorisation in this case, and wondering about the situation in which we can’t afford a load or the loop-carried values are calculated. Though I’m thinking the answer might be the NYF streamers.

Many of my queries seem to boil down to wanting to rearrange vector elements. In this case (and in many others, I think), a shuffle that can use two element sources would do the trick, though two shuffles and a pick can do the same, if they can all run at the same cycle edge.

Would it then depend on the compiler spotting and optimizing the pattern, without obvious programmer feedback to let them know whether or not the optimization has been applied? With the ARM/x64 versions, one can at least tell by looking at the code that it has been heavily optmised, though competence can be hard to gauge and the code is hard to understand.