On Tue, Jan 21, 2014 at 4:07 PM, Kirill Yukhin <[email protected]> wrote:
>> > I have a doubts about changes to sse.md. >> > I've splitted existing (SF-only) patterns into 2: DF and SF. >> > As far as insn operands and final instruction have no such data >> > type discrimination I set this data type to (mem:..) part. >> > Having this (for SF): >> > (define_expand "avx512pf_scatterpf<mode>sf" >> > [(unspec >> > [(match_operand:<avx512fmaskmode> 0 "register_or_constm1_operand") >> > (mem:SF >> > ... >> > >> > instead of this: >> > (define_expand "avx512pf_scatterpf<mode>" >> > [(unspec >> > [(match_operand:<avx512fmaskmode> 0 "register_or_constm1_operand") >> > (mem:<ssescalarmode> >> > ... >> > >> > Not sure if this (DI/SI) mode for mem is needed. Moreover, not sure what >> > that data type represents. >> >> Did you try to add DF/SF mode to the unspec? I am not familiar with >> this insn, but shouldn't the mode of mem access be somehow similar to >> the avx512f_scattersi<mode> access? >> >> Also, you can use double macroization with MODEF iterator for SF and DFmode. > > It seems that patch is (at last!) non-trivial, so I am splitting out trivial > part > in order to reduce volume. > > It is in the bottom. > > Bootstrapped, avx-512* tests pass, sse-* tests pass. Ok for trunk? OK with a proper ChangeLog. Thanks, Uros.
