This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Stack Pointer/Size on GIMPLE?


Hi Luke,

thank you very much for your answer!

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.
That is exactly what I had in mind. May I assume that you are part of
the group working on RochesterSTM?

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.
We were not sure about the overhead and do not have any comparisons so far, but we thought that there are some cases where it is faster to copy the stack. (rarely aborting transactions with frequent accesses to stack variables). Do you know any papers comparing the different approaches?

Right now, I am not sure that we are able to detect stack accesses statically, but I figured it should be possible inside the GCC. But assuming it would be possible to do so, how would a lightweight lazy checkpoint scheme look like? Would it be like Intels approach mentioned in the paper below?

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.
TinySTM supports write-buffering (called write-back) and undo-log
based versioning (called write-through). The idea of copying the stack
comes from Tanger. This is an LLVM-based compiler environment that
supports code generation for TinySTM. Saving the stack can be switched off by specifying a command-line option.
At first sight stack copying seemed a reasonable solution and looked straightforward to implement. After experiencing some difficulties accessing the necessary data if we want to restrict ourselves to the tree representation, maybe we should simply go for the approach of instrumenting the stack variables as well.


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.
We are familiar with the paper, but this approach would require to go to RTL level or maybe even beyond. From my current point of view this seemed not tempting.

Regards,
Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]