Re: [PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

2022-05-27 Thread Jan Beulich via Gcc-patches
On 27.05.2022 10:57, Uros Bizjak wrote: > On Fri, May 27, 2022 at 10:05 AM Jan Beulich wrote: >> >> It's pretty clear that the operand numbers in the MEM_P() checks are >> off by one, perhaps due to a copy-and-paste oversight (unlike in most >> other places here we're dealing with two outputs). >>

Re: [PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

2022-05-27 Thread Uros Bizjak via Gcc-patches
On Fri, May 27, 2022 at 10:05 AM Jan Beulich wrote: > > It's pretty clear that the operand numbers in the MEM_P() checks are > off by one, perhaps due to a copy-and-paste oversight (unlike in most > other places here we're dealing with two outputs). > --- > What I don't understand is why operand 2

[PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

2022-05-27 Thread Jan Beulich via Gcc-patches
It's pretty clear that the operand numbers in the MEM_P() checks are off by one, perhaps due to a copy-and-paste oversight (unlike in most other places here we're dealing with two outputs). --- What I don't understand is why operand 2 is "nonimmediate_operand", not "register_operand" (which afaict