On Wed, 2020-04-22 at 07:59 -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Apr 21, 2020 at 04:53:53PM -0500, Aaron Sawdey via Gcc-
> patches wrote:
> > For future architecture with prefix instructions, always use
> > plq/pstq
> > rather than lq/stq for atomic load of quadword. Then we never have
> > to
> > do the doubleword swap on little endian. Before this fix, -mno-
> > pcrel
> > would generate lq with the doubleword swap (which was ok) and
> > -mpcrel
> > would generate plq, also with the doubleword swap, which was wrong.
> > 2020-04-20  Aaron Sawdey  <acsaw...@linux.ibm.com>
> > 
> >     PR target/94622
> >     * config/rs6000/sync.md (load_quadpti): Add attr "prefixed"
> >     if TARGET_PREFIXED.
> >     (store_quadpti): Ditto.
> >     (atomic_load<mode>): Do not swap doublewords if TARGET_PREFIXED
> > as
> >     plq will be used and doesn't need it.
> >     (atomic_store<mode>): Ditto, for pstq.
> > +;; Pattern load_quadpti will always use plq for atomic TImode if
> > +;; TARGET_PREFIXED.  It has the correct doubleword ordering on
> > either LE
> > +;; or BE, so we can just move the result into the output register
> > and
> > +;; do not need to do the doubleword swap for LE. Also this avoids
> > any
> > +;; confusion about whether the lq vs plq might be used based on
> > whether
> > +;; op1 has PC-relative addressing. We could potentially allow BE
> > to
> > +;; use lq because it doesn't have the doubleword ordering problem.
> 
> Two spaces after dot (twice).
> 
> Thanks for the nice comments :-)
> 
> > -  [(set_attr "type" "store")])
> > +  [(set_attr "type" "store")
> > +   (set (attr "prefixed") (if_then_else (match_test
> > "TARGET_PREFIXED")
> > +                                        (const_string "yes")
> > +                                        (const_string "no")))])
> 
> Every 8 leading spaces should be a tab (it's annoying to have a
> mixture
> of styles, and then later to have patches randomly change such things
> as
> well.  Spaces everywhere (no tabs ever) works fine for me, but that
> is
> not what we use, not in GCC, and not in our port.  We could change
> that
> in GCC 11 perhaps?  Opinions?)

Keep the port consistent with the rest of the project, whatever it is.
I tend to prefer just tabs, but also like to have >80 column windows.  
:-)

thanks
-Will


> 
> The patch is okay for trunk modulo those nits.  Thanks!
> 
> 
> Segher

Reply via email to