This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GCC RFC]A new and simple pass merging paired load store instructions

On 05/15/14 12:41, Mike Stump wrote:
On May 15, 2014, at 10:13 AM, Jeff Law <> wrote:
I've poked at the scheduler several times to do similar stuff, but
was never really satisfied with the results and never tried to
polish those prototypes into something worth submitting.

What was lacking?  The cleanliness of the patch or the, it didn’t win
me more than 0.01% code improvement so I never submitted it?
Cleanliness and applicability of my implementation.

For fmpyadd/fmpysub on the PA, my recollection was that the right way to go was to detect when both were in the ready queue at the same time, then resort the queue to have them issue consecutively. We didn't have the necessary hooks to have target dependent code examine and rearrange the queues back when I looked at this. By the time we had those capabilities, the PA8000 class processors had been released and those instructions were considered bad so I never came back to this.

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.

Trivial to do with my patch, just change the sort key to arrange that
to happen, however, if you want multiple support and this, then, you
need to recognize store_m / load from a part of that, which would be
kinda annoying.
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.

Arguably one could throttle down the issue rate for these scheduler-like passes which makes that problem go away.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]