> Yes, this is for the GPU, and yes, SIMT is the way to think of it. The > vectorizer would not be enabled for this code. That would not go well! > >> But I don't see how vectorization, even simple one, is easier at RTL level. >> What about divergence, calls, aliasing, loops? Or is your target much >> narrower? > > Divergence is a high-level concept that does not really exist at the > assembler level (GCN has fork/join instructions, but then says not to > use them in all but "irreducible cases" -- they simply loop until all > the mask variations are exhausted). > > Calls are not an issue in themselves (provided all parameters fit in > registers). > > Aliasing is no more of an issue than it would be in the original scalar > code because the threads are required to be "independent". > > Loops work just fine, as long as the masks are managed correctly.
> Some things are easier at gimple level, and some are easier at RTL. > The RTL level requires fewer changes that end up in discussions like > this one. ;-) So you're transforming scalar "kernels" to SIMT and all prerequisites are already checked? I don't think I'll be able to get a full picture of your use case but to me it still sounds like a gimple-level problem, conceptually (when ignoring the fact that, currently, we cannot express it in gimple). >> Yeah, one of the main reasons for vec_predicate as a "first-class" citizen is >> that we should not be able use its constituents context free. Under that >> model >> a vec_merge is already an atomic operation, a predicated reg-move. I >> wouldn't >> re-use vec_merge of course but we'd have something like >> (set (reg...) (vec_predicate [(reg ...)] vmask velse ...)) > > So, it would be another way to write vec_merge, but with different > behaviours/restrictions in certain passes? A vec_merge is just a merge of two unpredicated inputs, vec_predicate is supposed to directly represent predication with mask, length etc. so a bit more comprehensive than vec_merge. Also, the intention is to make predication/masking more regular in the RTL passes. Once it gets interesting, i.e. stores, moves, vec_predicate alone also isn't enough. But as indicated, separate topic and doesn't help you directly here, apologies for derailing. -- Regards Robin
