On 05.07.2023 10:40, Hongtao Liu wrote: > On Wed, Jul 5, 2023 at 4:00 PM Jan Beulich via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> >> The middle alternative each was unusable without enabling AVX512DQ (in >> addition to AVX512VL), which is entirely unrelated here. The last >> alternative is usable with AVX512VL only (due to type restrictions on >> what may be put in the upper 16 YMM registers), and hence is pointlessly >> forcing 512-bit mode (without actually reflecting that in the "mode" >> attribute). > Ok.
Thanks. >> --- >> Like elsewhere I suspect "prefix_extra" is bogus here and should be >> dropped. >> >> Is "sselog1" actually appropriate here? Extracts are special forms of >> moves after all, not logical operations. Even "sseshuf1" would seem to >> come closer. > Honestly, I don't know why it's marked as sselog1, but looking at the > code, almost all vec_extract patterns are marked as sselog1, guess > it's originally from pextr. > Agree that it's should be more close to shuffle instructions. Yet as said I think these are special forms of moves. To me "shuffle" involves more than one element. Yet then I don't really know what the "type" attributes are used for (other than vaguely "for scheduling"), and hence whether treating extracts as shuffles would be more appropriate. (IOW I'd be happy to make a patch to convert all extracts, but I'd need to know whether the conversion should be to "sseshuf", "sseshuf1", or "ssemov". In the former two cases knowing the "Why?" would also help, especially for writing a sensible description. I also haven't found any explanation towards the difference between sse<type> and sse<type>1: The "memory" attribute evaluates to "both" for the 1 forms if operand 1 is in memory, yet that doesn't seem to fit any of the uses here.) Jan
