This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [GCC RFC]A new and simple pass merging paired load store instructions
- From: Mike Stump <mikestump at comcast dot net>
- To: Jeff Law <law at redhat dot com>
- Cc: "bin.cheng" <bin dot cheng at arm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 15 May 2014 14:25:05 -0700
- Subject: Re: [GCC RFC]A new and simple pass merging paired load store instructions
- Authentication-results: sourceware.org; auth=none
- References: <004d01cf700e$ef1e30e0$cd5a92a0$ at arm dot com> <32B4330F-1D0F-4D4E-BF7A-2E5B2148B893 at comcast dot net> <5374F59D dot 3030101 at redhat dot com> <11986FC6-32E8-4C4F-AA8D-9B9E8C093FD5 at comcast dot net> <53751D10 dot 7090604 at redhat dot com>
On May 15, 2014, at 1:01 PM, Jeff Law <law@redhat.com> wrote:
> For the memory optimizations, IIRC, the dependencies keep them from getting into the ready queue at the same time. Thus it's significantly harder to get them to issue consecutively when you've got an issue rate > 1.
> But if you've got an issue rate > 1, then it's a lot less likely you'll get the store/load pairing up the way you want.
Ah, yeah, on second thought, that won’t work if they are not ready together…
I sort the ready queue:
first ready set:
load
store
everything else
next ready set:
load store
everything else
Now, it might work, if there are no other instructions and no loads in the next set, and so on, but that would be an accident. The utility is only in instructions that are ready together, though, tick boundaries and issue rates don’t matter any, as I don’t care about ticks or issue rates. The only consideration on order is my ordering operator and once ordered, the target is free to combine as it sees fit. So, for store load optimization, my patch is rather useless.