Improvements of the haifa scheduler

Vladimir Makarov vmakarov@redhat.com
Mon Mar 5 16:20:00 GMT 2007


Andrey Belevantsev wrote:

> Vladimir N. Makarov wrote:
>
>> Good aliasing is very important for the scheduler.  But I'd look at 
>> this more wider.  We need a good aliasing for many RTL 
>> optimizations.  What's happened to ISP RAS aliasing patch propagating 
>> SSA info to RTL?  Why is it stalled?
>
> We'll plan to work on it further in the near future.  The initial plan 
> was to update it to trunk, then to gather the new numbers of 
> disambiguations and stuff, then to check the consistency of the saved 
> information via some verifier.
>
>> As for Sanjiv Gupta's aliasing work, that was interesting but as I 
>> remember the patch made compiler too slow (like 40% slower).  You 
>> should make this approach faster to make it accepted as used by default.
>
> Alexander Monakov was working on it in the last year (CC'd).  I have 
> looked through his paper to recall what was done:
>
> - instead of iterating over cfg, a single iteration in topological 
> order was made to calculate address descriptors (which was enough for 
> using this info in the scheduler);
> - instead of one per-function hashtable for all address descriptors, 
> separate per-bb hashtables were introduced, lowering the time needed 
> to access hashtables;
> - instead of saving out lists of descriptors for each bb, in lists 
> were saved (and not recalculated several times);
> - saving descriptors for each mem instead of each bb.  Earlier, when 
> an aliasing query was made, we've searched for insns corresponding to 
> mems via hashtable, then reanalyzed a basic block up to that insns, 
> then answered on the query using calculated address descriptors.  
> After the fix, we've just got the final descriptor from the first 
> hashtable, then answered the query.
>
> After all fixes, bootstrap and cc1-i-files compiled slower on 2%.  The 
> compiler built with the patch enabled compiled tramp3d on 0.5% faster 
> and produced 0.6% faster code.  We'll dig out this patch together with 
> the rest of aliasing patches and will send it as a RFC.  It is my 
> mistake for not doing this earlier.

That is a real progress with Gupta's patch.  Thank you for working on it.

>
>> If you need benchmarking for machines (like ppc) you have no access 
>> to, I can provide the benchmarking.
>
> That's great, because we have access to powerpc750 only.  I have used 
> it to try the scheduler on ppc, but that was slow.
>
I'll do some PPC benchmarking of your branch on this week and send the 
results.



More information about the Gcc mailing list