> I see what you mean about the caller/callee relationship in the example
> you gave. If the caller uses call/add to do the call and also compute a
> pointer to data, and the callee only receives this as an ordinary pointer
> (not as the basis for further PIC computations), there's nothing
> interprocedural going on for Purify to have to recognize.
>
> Sadly, today's Purify does not handle this call/add pair for passing a
> pointer to nearby data. It's not impossible for us to add a recognizer for
> this pattern, but we don't have one now.
And the only difference would be to relax pattern recognition so that
delay slot is examined for %o7-based arithmetic for all call
instructions, not only call .+8 in particular. Is this correctly understood?
> Oh, by the way: when Purify stretches code, we don't try to preserve
> alignment above what's needed for correct operation, so tables that start
> with directives like ".align 64" might not stay aligned. If that's just
> for cache-line efficiency, there's no problem, it'll just run slower. (And
> if you're using Purify, the performance ship has already sailed.) But if
> your algorithm relies on the low six bits of the address being zero,
> you'll lose. The same goes for all the align directives I see. I hope
> that's not a problem.
Not at the moment, no.
> Further thoughts?
When does Purify stretch code more specifically? Always (because it
might have to inject some prologue/epilogue to every function)? Or only
when is has to compensate for "mishaps" when single add %o7,const,%??
has to be replaced with several instructions (because const is limited
to 13 bits)? Question basically is what are the chances for something
like earlier mentioned
1: call _sparcv9_AES_encrypt
sub %o7,1b-AES_Te,%o4
to be *unaffected* by Purify? I mean if Purify does *not* stretch
anything between AES_Te and 1:, then it would work just fine, wouldn't
it? I'm not saying that I refuse to make aes-sparcv9 module
Purify-friendly (it is patched already as per
http://cvs.openssl.org/chngview?cn=17898), I still want to fully
understand "rules of engagement":-) A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
