On Wed, Jul 5, 2023 at 4:55 PM Jan Beulich <jbeul...@suse.com> wrote: > > 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 I think if it only extracts from the low part, it's close to a move, otherwise it's more like shuffle(shuffle the specific elements to the low part). I guess one possible reason it's marked as sselog1 is from port usage perspective, it's more close to vector logic instructions? > the "type" attributes are used for (other than vaguely "for > scheduling"), and hence whether treating extracts as shuffles would AFAI, it's only used by scheduling, I don't know if there're tools based on GCC schedule model. > 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.) I think sse<type>1 only has one input operand, but sse<type> may have two or more. For instruction perspective, they're the same type, sse<type>1 is introduced to avoid Segment Fault in define_memory_attr which will check operands[2] or operands[3]. (Similar for other attribute default setting) > > Jan
-- BR, Hongtao
