On 28/10/2024 20:03, Robin Dapp wrote:
I'm not sure how this is different to just deleting the
zero-initializer, which is what I already tested and found some random
behaviour?

The difference is in the else-operand predicate.  So unless there are
more bugs we should only have added VCOND_EXPRs for the cases where
they are absolutely necessary and not unconditionally as currently done
in the gcn backend.

Except that the init_regs pass just puts it straight back in.... I'm testing this additional patch:

--- a/gcc/config/gcn/gcn-valu.md +++ b/gcc/config/gcn/gcn-valu.md @@ -4000,7 +4000,7 @@ (define_expand "maskload<mode>di" rtx v = gen_rtx_CONST_INT (VOIDmode, MEM_VOLATILE_P (operands[1])); emit_insn (gen_gather<mode>_expr_exec (operands[0], addr, as, v, - operands[0], exec)); + gcn_gen_undef(<MODE>mode), exec)); DONE; })

Is this just a way to pass "undefined" to a pattern?


Anyway, I have some tests running, so we'll see what happens.

Yep, that's how we tell the vectorizer to expect and undefined value
in the inactive elements.  Did your tests return any reasonable result?

Sorry, I forgot to report back.... No, there were no suspicious test failures.

Andrew

Reply via email to