On Thu, May 28, 2026 at 11:58 AM Uros Bizjak <[email protected]> wrote: > > On Thu, May 28, 2026 at 11:48 AM Jakub Jelinek <[email protected]> wrote: > > > > On Thu, May 28, 2026 at 11:31:27AM +0200, Uros Bizjak wrote: > > > Hm, OTOH, is this condition correct: > > > > > > case TYPE_LEA: > > > if (TARGET_APX_NDD && <nf_applied>) > > > return "%{nf%} add{<imodesuffix>}\t{%2, %1, %0|%0, %1, %2}"; > > > else > > > return "#"; > > > > > > Should it be "TARGET_APX_NDD || <nf_applied>"? > > > > The pattern is weird, but TARGET_APX_NDD || <nf_applied> would be wrong. > > Without TARGET_APX_NDD there is no 3 operand add, so we can't use that. > > Of course, question is if there will be CPUs with just APX-NF and not > > APX-NDD or with just APX-NDD and not APX-NF. > > > > I'd say it is a bad idea to have the "lea" variant come before the > > 3 apx_ndd variants, if the lea variant came last, then at least the r <- r, > > l > > case would be covered for TARGET_APX_NDD by the earlier (but now later) > > r <- rje, r variant and could then emit either the 3 operand add or 3 > > operand add with {nf}. Anyway, with the current position it could also be > > if (TARGET_APX_NDD) > > return "<nf_prefix>add{<imodesuffix>}\t{%2, %1, %0|%0, %1, %2}"; > > else > > { > > operands[3] = gen_rtx_PLUS (<MODE>mode, operands[1], operands[2]); > > return "lea{<imodesuffix>}\t{%E3, %0|%0, %E3}"; > > } > > I think that the correct solution is to put LEA at the end. LEA > alternative is intended for non-NDD cases to allow two-register > operation, but NDD should override it, w/ or w/o NF. Let's ask > Hongtao.
Eh, a thinko. *Without* NDD, we still need LEA. Let's go forward with your patch, it is the safest solution. Uros.
