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

[Duraid Madina]

Jim Wilson wrote:
> There is some potential for confusion over what the pragma applies to. 
> In a more complex example, the following line might contain more than
> one statement, or one statement might be spread over several lines, or
> the next line may contain a control-flow statement like an if.  In some
> of these cases, it might not be clear what to do unless this is defined
> well.

Agreed, a simple pragma isn't really up to the task, but it seemed 
easier than dredging up this information from profile feedback.

> I think there is no hope of implementing this in the current RTL
> optimizers.  This would have to be done in the tree-ssa infrastructure
> which is not yet in the mainline compiler, but hopefully coming soon.

This will be the entry point for a new wave of GCC hackers, I hope!

> But if we are running both threads on a single IA-64 cpu, then they are
> now running in lock-step and things break down.  If the second thread
> stalls because of a cache miss or page fault, then the primary thread
> stalls too, so now the secondary thread is slowly down the primary
> thread in some cases which is undesirable.  This doesn't seem to work
> unless we use prefetch instructions in the secondary thread, and now we
> aren't doing speculative precomputation anymore.  We are just doing
> simple prefetching.

On that note, does GCC *ever* emit ld8.a / chk.a pairs? This would be a 
very nice addition for yucky pointer code, and isn't the can of worms 
for the compiler that ld.s/chk.s is.

> Yes.  You might not be able to get rid of as many nops as you hoped
> because of packing limitations.

If 1% of those nops turn into chk.a instructions, I'll be very pleased.. 
Bring on tree-ssa! :)

	Duraid