user-guided speculative precomputation? (my wacky ia64 idea)

Duraid Madina duraid@octopus.com.au
Thu Apr 1 00:07:00 GMT 2004


Hi GCCers,

	I was bored enough to look through some IA64 emitted by GCC and noticed 
that IU utilization was in most places pretty horrid. nops everywhere! 
Oh well.

	I thought to myself, why does GCC even bother issuing to 6 ports? How 
bad would it be if I clamped it down to 4? A few hours later, I had my 
answer: _not too bad_. By my hackish estimations (I haven't gone ahead 
and bootstrapped an appropriately crippled compiler, but instead just 
performed some calculations on 'representative' (short) instruction 
traces to back-of-the-envelope accuracy ;) and it looks like SPECint2k 
will lose "only" around 20% performance.

	Then I thought, why not treat such a wide machine as a multithreaded 
one, but where one thread doesn't have any flow control instructions? ;) 
i.e. instead of sprinkling nops all over the place, just give up and 
deliberately reserve an instruction out of every bundle for another 
stream of execution.

	What to do with such a stream? Well, why not support speculative 
precomputation? (aggressively chase pointers so as to prefetch data into 
cache before the "main" thread needs it, as in "Memory Latency-Tolerance 
Approaches for Itanium Processors" by Wang et al, in proc. HPCA'02) It's 
tricky to do this automatically, but my question to the group is: would 
it be sensible to add support for something like a "#pragma 
delinquent_load" that could be inserted at the appropriate point in e.g. 
graph/tree/list traversal code etc.? A "cookie cutter" prefetching 
sequence could then be fitted in the reserved area alongside the main 
thread, silently prefetching data more intelligently than any non-insane 
hardware prefetcher could ever hope to. OoO is great, but I've yet to 
see one that can keep track of things hundreds of cycles out...

	The potential gains seem phenomenal, particularly for in-order machines 
such as the (current) Itanium line, but one wonders if it couldn't also 
help other architectures, at least in mitigating L2/L3 misses.

	Duraid

P.S. The real question, of course, is whether or not this post is an 
April fool's joke. ;)



More information about the Gcc mailing list