public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Sameera Deshpande <Sameera.Deshpande@imgtec.com>
To: Richard Sandiford <rdsandiford@googlemail.com>
Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>,
	"gcc-patches@gcc.gnu.org"	<gcc-patches@gcc.gnu.org>
Subject: RE: [PATCH][MIPS] Enable load-load/store-store bonding
Date: Mon, 23 Jun 2014 09:18:00 -0000	[thread overview]
Message-ID: <38C8F1E431EDD94A82971C543A11B4FEE0BB2F@PUMAIL01.pu.imgtec.org> (raw)
In-Reply-To: <8761ju8c2k.fsf@talisman.default>

Hi Richard,

Thanks for your comments. I am working on the review comments, and will share the reworked patch soon.
However, here is clarification on some of the issues raised.

> > +  if (TARGET_FIX_24K && TUNE_P5600)
> > +    error ("unsupported combination: %s", "-mtune=p5600 -mfix-24k");
> > +
> >    /* Save the base compression state and process flags as though we
> >       were generating uncompressed code.  */
> >    mips_base_compression_flags = TARGET_COMPRESSION;
> 
> Although it's a bit of an odd combination, we need to accept -mfix-24k -
> mtune=p5600 and continue to implement the 24k workarounds.
> The idea is that a distributor can build for a common base architecture, add -
> mfix- options for processors that might run the code, and add -mtune= for
> the processor that's most of interest optimisation-wise.
> 
> We should just make the pairing of stores conditional on !TARGET_FIX_24K.
We had offline discussion based on your comment. There is additional view on the same.
Only ISAs mips32r2, mips32r3 and mips32r5 support P5600. Remaining ISAs do not support P5600. 
For mips32r2 (24K) and mips32r3 (micromips), load-store pairing is implemented separately, and hence, as you suggested, P5600 Ld-ST bonding optimization should not be enabled for them.
So, is it fine if I emit error for any ISAs other than mips32r2, mips32r3 and mips32r5 when P5600 is enabled, or the compilation should continue by emitting warning and disabling P5600?
Also, the optimization will be enabled only if !TARGET_FIX_24K && !TARGET_MICTOMIPS as suggested by you.

> > +
> > +#define ENABLE_LD_ST_PAIRING \
> > +  (TARGET_ENABLE_LD_ST_PAIRING && TUNE_P5600)
> 
> The patch requires -mld-st-pairing to be passed explicitly even for -
> mtune=p5600.  Is that because it's not a consistent enough win for us to
> enable it by default?  It sounded from the description like it should be an
> improvement more often that not.
> 
> We should allow pairing even without -mtune=p5600.
Performance testing for this patch is not yet done. 
If the patch proves beneficial in most of the testcases (which we believe will do on P5600) we will enable this optimization by default for P5600 - in which case this option can be removed.

> 
> Are QImodes not paired in the same way?  If so, it'd be worth adding a
> comment above the define_mode_iterator saying that QI is deliberately
> excluded.
The P5600 datasheet mentions bonding of load/stores in HI, SI, SF and DF modes only. Hence QI mode is excluded. I will add the comment on the iterator.

- Thanks and regards,
   Sameera D.

  reply	other threads:[~2014-06-23  9:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <38C8F1E431EDD94A82971C543A11B4FEE0A588@PUMAIL01.pu.imgtec.org>
2014-06-21 16:25 ` Richard Sandiford
2014-06-23  9:18   ` Sameera Deshpande [this message]
2014-06-23  9:41     ` Richard Sandiford
2014-06-24 10:42   ` Sameera Deshpande
2015-03-30 11:28     ` sameera
2015-04-20  5:09       ` sameera
2015-04-20 18:30         ` Mike Stump
2015-04-20 19:09         ` Matthew Fortune
2015-04-20 22:01           ` Moore, Catherine
2015-05-11 11:05           ` sameera
2015-05-11 12:13             ` Matthew Fortune
2015-05-11 12:39               ` sameera
2015-05-11 16:40             ` Mike Stump
2015-05-13  7:39               ` sameera
2014-06-19  9:41 Sameera Deshpande

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38C8F1E431EDD94A82971C543A11B4FEE0BB2F@PUMAIL01.pu.imgtec.org \
    --to=sameera.deshpande@imgtec.com \
    --cc=Matthew.Fortune@imgtec.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rdsandiford@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).