On 10/13/2015 02:16 PM, Bernd Schmidt wrote:
_Potentially_ so, yes. However, GCC is free to put the allocation into
an otherwise-unused part of the stack frame.
Well, I looked at code generation changes, and it usually seems to come
with an increase in stack frame size - sometimes causing extra
instructions to be emitted.
I think that's essentially unavoidable when we end up using the scratchpad.
However, why do we need to allocate anything in the first place?
> If you want to store something that will be thrown away,
> just pick an address below the stack pointer.
Because allocating a scratchpad should work on all relevant targets. We
do not have the resources to test on all GCC-supported
CPU ISAs and on all GCC-supported OSes, and we would like to have an
optimization that works on as many targets as makes sense
[those with cmove-like ability and withOUT full-blown conditional
execution].
Yeah, but if you put in a new facility like this, chances are
maintainers for active targets will pick it up and add the necessary
hooks. That's certainly what happened with shrink-wrapping. So I don't
think this is a concern.
But won't you get valgrind warnings if the code loads/stores outside the
defined stack? While we know it's safe, the warnings from valgrind will
likely cause a backlash of user complaints.
I'm afraid I'll have to reject the patch then, on these grounds:
* it may pessimize code
* it does not even estimate costs to attempt avoiding this
* a much simpler, more efficient implementation is possible.
Noted. I think the pessimization is the area were folks are most concerned.
Obviously some pessimization relative to current code is necessary to
fix some of the problems WRT thread safety and avoiding things like
introducing faults in code which did not previously fault.
However, pessimization of safe code is, err, um, bad and needs to be
avoided.
Jeff
