Hi Uros,

> -----Original Message-----
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Friday, March 04, 2016 1:10 AM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [Patch X86_64] : Fix type attribute for sseimul reservations in
> znver1.md
> 
> On Thu, Mar 3, 2016 at 7:05 PM, Kumar, Venkataramanan
> <venkataramanan.ku...@amd.com> wrote:
> > Hi Maintainers,
> >
> > The below patch corrects the type attribute  for "sseimul" type
> reservations in znver1.md.
> >
> > (snip)
> > diff --git a/gcc/config/i386/znver1.md b/gcc/config/i386/znver1.md
> > index 3db3bed..feeccd7 100644
> > --- a/gcc/config/i386/znver1.md
> > +++ b/gcc/config/i386/znver1.md
> > @@ -913,28 +913,28 @@
> >  (define_insn_reservation "znver1_sseimul" 3
> >                          (and (eq_attr "cpu" "znver1")
> >                               (and (eq_attr "mode" "TI")
> > -                                  (and (eq_attr "type" "ssemul")
> > +                                  (and (eq_attr "type" "sseimul")
> >                                         (eq_attr "memory" "none"))))
> >                          "znver1-direct,znver1-fp0*3")
> >
> >  (define_insn_reservation "znver1_sseimul_avx256" 4
> >                          (and (eq_attr "cpu" "znver1")
> >                               (and (eq_attr "mode" "OI")
> > -                                  (and (eq_attr "type" "ssemul")
> > +                                  (and (eq_attr "type" "sseimul")
> >                                         (eq_attr "memory" "none"))))
> >                          "znver1-double,znver1-fp0*4")
> >
> >  (define_insn_reservation "znver1_sseimul_load" 7
> >                          (and (eq_attr "cpu" "znver1")
> >                               (and (eq_attr "mode" "TI")
> > -                                  (and (eq_attr "type" "ssemul")
> > +                                  (and (eq_attr "type" "sseimul")
> >                                         (eq_attr "memory" "load"))))
> >                          "znver1-direct,znver1-load,znver1-fp0*3")
> >
> >  (define_insn_reservation "znver1_sseimul_avx256_load" 8
> >                          (and (eq_attr "cpu" "znver1")
> >                               (and (eq_attr "mode" "OI")
> > -                                  (and (eq_attr "type" "ssemul")
> > +                                  (and (eq_attr "type" "sseimul")
> >                                         (eq_attr "memory" "load"))))
> >                          "znver1-double,znver1-load,znver1-fp0*4")
> >
> > @@ -942,13 +942,13 @@
> >                          (and (eq_attr "cpu" "znver1")
> >                               (and (eq_attr "mode" "DI")
> >                                    (and (eq_attr "memory" "none")
> > -                                       (eq_attr "type" "ssemul"))))
> > +                                       (eq_attr "type" "sseimul"))))
> >                          "znver1-direct,znver1-fp0*4")
> > (Snip)
> >
> > Changelog
> >
> > 2016-03-03  Venkataramanan Kumar
> <venkataramanan.ku...@amd.com>
> >
> >        Fix sseimul type attribute.
> >        * config/i386/znver1.md
> >        (znver1_sseimul, znver1_sseimul_avx256, znver1_sseimul_load,
> >        znver1_sseimul_avx256_load,  znver1_sseimul_di,
> >        znver1_sseimul_load_di) : Fix the type attribute.
> >
> > Ok for trunk if bootstrap and testing passes?
> 
> OK.
> 
> BTW: This patch is trivial, according to [1]. The criteria is simply:
> 
> Obvious fixes can be committed without prior approval. Just check in
> the fix and copy it to gcc-patches. A good test to determine whether a
> fix is obvious: will the person who objects to my work the most be
> able to find a fault with my fix? If the fix is later found to be
> faulty, it can always be rolled back. We don't want to get overly
> restrictive about checkin policies.
> 
> [1] https://gcc.gnu.org/svnwrite.html
> 

Thank you I up-streamed in trunk. 
One small change I also did  is reduced the latency by 1 for DI mode in those 
pattern. 
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=234007

regards,
Venkat.

> Thanks,
> Uros.

Reply via email to