On Tue, 29 Oct 2024, Andrew Stubbs wrote: > 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:
Yes, stupid pass, masking some latent issues in DF(?) > --- 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 > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
