Re: Stack Pointer/Size on GIMPLE?

[Luke Dalessandro <luked at cs dot rochester dot edu>]

> Is there a way to 
> access stack pointer and stack size (and the direction in which the 
> stack is growing) on the tree level?
>
> The explanation why I want to save the stack contents is the following:
> Code:
>
> ... use stack variables
>
> __tm_atomic { /* begin transaction */
>
> access shared locations in here
>
> } /* may rollback */
>
> In case of a rollback the original context of the thread must be 
> restored so that it may execute the transaction again. This will be done 
> using setjmp/longjmp. To prevent instrumenting all accesses to stack 
> variables inside the transaction with STM runtime calls, the stack 
> should be copied back from memory and the previous state of the stack 
> variables is restored.
>
> Any suggestions are helpful, thank you very much.

Hi Martin,

I don't know anything about GIMPLE, but I can address this issue. It sounds 
like you are proposing to checkpoint (via copying) the entire stack eagerly at 
the time you enter a transaction, in order to avoid transactional 
instrumentation of stack accesses.

This is probably a bad idea, as the overhead of the instrumentation is 
probably much less than the overhead of copying and restoring the stack. 
You're also relying on your ability to detect stack accesses statically (in 
order not to instrument them). If you can do this, then you can probably just 
implement a lightweight lazy checkpoint scheme rather than an eager, full copy.

I think, based on your first post 
(http://gcc.gnu.org/ml/gcc/2008-06/msg00193.html), that you are attempting to 
interface with TinySTM, which does lazy versioning (write-buffering) anyway if 
I recall correctly, so writes are going to be buffered aren't going to be 
written back on an abort anyway, which is what you want.

If you are thinking about an eager versioning system, then you should take a 
look at how stack access is dealt with in "Code Generation and Optimization 
for Transactional Memory Constructs in an Unmanaged Language" 
(http://portal.acm.org/citation.cfm?id=1251974.1252529), as the real issue is 
trying to "undo" accesses into stack space between the setjmp and the longjmp.

Hope this helps.

Luke