Re: Will a memory location be written to within a section of code?

On Mar 25, 7:12 pm, Peter Scott <sketer...@gmail.com> wrote:
> I'm working on hardware transactional memory: have start-transaction
> and end-transaction instructions, and anything between those
> instructions is supposed to either happen atomically or not at all, as
> far as other transactions are concerned. A way of speeding up some
> forms of HTM is to use a special read-with-intent-to-write-later
> instruction for memory reads when I know (or suspect) that the same
> memory location will be written to later in the transaction. I want a
> compiler to use these special read-with-intent-to-write-later
> instructions when appropriate, automatically. For example, in this
> code the compiler knows that foo will be written to after it is read:
>
> volatile int foo = 0;
> /* ... */
> transaction {
> foo = some_function(foo);
>
> }
>
> I want to be able to determine when a memory load will have a
> corresponding memory write later within the current transaction. For
> cases like the one above, finding this out is trivial: just look for
> matched memory loads and stores. But what if the load or store happen
> in another function, like a getter/setter method? Like this:
>
> volatile int foo = 0;
> int get_foo(void) { return foo; }
> void set_foo(int x) { foo = x; }
> /* ... */
> transaction {
> set_foo(some_function(get_foo()));
>
> }
>
> I don't need to detect all cases, just as many as possible. Is there a
> decent way to do this? I'm afraid I'm a newbie to compiler theory, so
> if there's a well-established type of analysis that would fit this
> problem, just telling me what it's called would be very helpful.


If the optimizer first does extensive inlining of calls within
transactions, then conventional basic block (DAGs, value numbering,
etc.) and intra-procedural flow analysis will work fine. Otherwise,
it will take inter-procedural (also called global) flow analysis. This
has traditionally been much trickier, but maybe not so much within
modern frameworks like LLVM (llvm.org).

Return to the comp.compilers page.
Search the comp.compilers archives again.