On 25.06.2023 08:41, Hongtao Liu wrote: > On Sun, Jun 25, 2023 at 2:35 PM Hongtao Liu <crazy...@gmail.com> wrote: >> >> On Sun, Jun 25, 2023 at 2:25 PM Jan Beulich <jbeul...@suse.com> wrote: >>> >>> On 25.06.2023 07:12, Hongtao Liu wrote: >>>> On Wed, Jun 21, 2023 at 2:29 PM Jan Beulich via Gcc-patches >>>> <gcc-patches@gcc.gnu.org> wrote: >>>>> >>>>> --- >>>>> For the purpose here (and elsewhere) bcst_vector_operand() (really: >>>>> bcst_mem_operand()) isn't permissive enough: We'd want it to allow >>>>> 128-bit and 256-bit types as well irrespective of AVX512VL being >>>>> enabled. This would likely require a new predicate >>>>> (bcst_intvec_operand()?) and a new constraint (BR? Bi?). (Yet for name >>>>> selection it will want considering that this is applicable to certain >>>>> non-calculational FP operations as well.) >>>> I think so. >>> >>> Any preference towards predicate and constraint naming? >> something like bcst_mem_operand_$suffiix, $suffix indicates the >> pattern may use zmm instruction for 128/256-bit operand. >> maybe just bcst_mem_operand_zmm? > For constraint, maybe we can reuse Br, relax Br to match bcst_mem_operand_zmm. > For those original patterns with bcst_mem_operand, it should be ok > since it's already guarded by the predicate, the constraint must be > valid.
Hmm, I wanted to get back to this, but then I started wondering about this reply of yours vs your request to not go farther with the use of "oversized" insns (i.e. acting in 512-bit registers in lieu of AVX512VL being enabled, when no FP exceptions can be raised on the otherwise unused elements). Since iirc the latter came later, am I right in assuming we then also shouldn't go the route outlined above? Jan
