On 8/22/23 02:08, juzhe.zh...@rivai.ai wrote:
Yes, I agree long-term we want every-thing be optimized as early as
possible.
However, IMHO, it's impossible we can support every conditional patterns
in the middle-end (match.pd).
It's a really big number.
For example, for sign_extend conversion, we have vsext.vf2 (vector SI ->
vector DI),... vsext.vf4 (vector HI -> vector DI), vsext.vf8 (vector QI
-> vector DI)..
Not only the conversion, every auto-vectorization patterns can have
conditional format.
For example, abs,..rotate, sqrt, floor, ceil,....etc.
I bet it could be over 100+ conditional optabs/internal FNs. It's huge
number.
I don't see necessity that we should support them in middle-end
(match.pd) since we known RTL back-end combine PASS can do the good job
here.
Besides, LLVM doesn't such many conditional pattern. LLVM just has "add"
and "select" separate IR then do the combine in the back-end:
https://godbolt.org/z/rYcMMG1eT <https://godbolt.org/z/rYcMMG1eT>
You can see LLVM didn't do the op + select optimization in generic IR,
they do the optimization in combine PASS.
So I prefer this patch solution and apply such solution for the future
more support : sign extend, zero extend, float extend, abs, sqrt, ceil,
floor, ....etc.
It's certainly got the potential to get out of hand. And it's not just
the vectorizer operations. I know of an architecture that can execute
most of its ALU and loads/stores conditionally (not predication, but
actual conditional ops) like target = (x COND Y) ? a << b ; a)
I'd tend to lean towards synthesizing these conditional ops around a
conditional move/select primitive in gimple through the RTL expanders.
That would in turn set things up so that if the target had various
conditional operations like conditional shift it could be trivially
discovered by the combiner.
We still get most of the benefit of eliminating control flow early, a
sensible gimple representation, relatively easy translation into RTL and
easy combination for targets with actual conditional operations.
It turns out that model is something we may want to work towards anyway.
We were looking at this exact problem in the context of zicond for
riscv. The biggest problem we've seen so far is that the generic
conditional move expansion generates fairly poor code when the target
doesn't actually have a conditional move primitive.
jeff
