Request for reviews (XXL): 6961690: load oops from constant table on SPARC

[Igor Veresov]

On 11/15/10 8:41 AM, Paul Hohensee wrote:
> Depends on the platform whether it's a win or not. When we did the original
> sparc64 port, it was faster to materialize 64-bit constants inline than
> to do
> a load. This was on U3s. Ditto U4s and U4+s when we tried them. Faster to
> do multi-issue (3 clocks max) than to tolerate a potential L1 miss.
>

Also, consider the edge case: a method that does only one load of a 
constant. In this case it is a full-blown cache miss with a high 
probability (the first time for sure). Whereas if a constant is embedded 
in the instruction stream it never is.

It would be interesting to compare cache-miss statistics (as well as the 
overall performance) for different styles of constant loading on 
T-series and M-series.

igor

> Paul
>
> On 11/15/10 8:45 AM, Christian Thalinger wrote:
>> On Nov 12, 2010, at 10:58 PM, Vladimir Kozlov wrote:
>>> Most important is why it is not under flag?
>>
>>
>> Hmm, I never thought about putting it under a flag since in theory
>> materializing the constant table base address only once instead of
>> every time it's required should always be a win.
>>
>> -- Christian