Speculative prefetching: report

Dale Johannesen dalej@apple.com
Tue Oct 12 21:26:00 GMT 2004


On Oct 12, 2004, at 12:31 PM, Andrew Pinski wrote:
> On Oct 12, 2004, at 3:17 PM, Dale Johannesen wrote:
>
>> 2.  In the profile-generation phase, there is a huge code bloat 
>> resutling from
>> instrumenting all the loads and stores.  This badly stresses the rest 
>> of the BE,
>> causing out-of-memory ICEs or unacceptably slow compile times (hours) 
>> on
>> several SPECmarks.  (With IMA to be sure.)
>
> This sounds like a huge problem with any code but should be fixed
> a different way than just disabling speculative prefetching because
> we could run into this a different way.  Maybe we should only
> profile load/stores in loops.

Longterm, yes, it can probably be made usable by doing things like this
(instrument only one of accesses to adjacent memory, don't instrument
stack refs or FP constants, etc.)   I hope so.  I doubt that sort of 
ongoing
heuristic tuning (probably target-dependent) is appropriate for stage 3
though.  I wasn't suggesting totally disabling it, just removing it from
-fprofile-generate/use; the option-specific flag is still there.

>> 3.  The SPECmarks which did build got consistently worse results.
>> I did no deep analysis, but it appears to be much too aggressive about
>> prefetching; it will prefetch each store of an unrolled memset loop 
>> individually,
>> for example  I think it needs some concept of cache line size to be 
>> useful.
>
> This is most likely the same problem as PR 17950.

Looks like.



More information about the Gcc mailing list