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

On Mar 26, 2:09 pm, Gene <gene.ress...@gmail.com> wrote:
> 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).


That helps a lot, thanks. The prediction doesn't need to be perfect,
so I believe that in a majority of cases, the inlining that something
like LLVM does will be enough, especially if the optimization is done
after the program is linked. I was pleasantly surprised to find that
llvm-ld does an inlining pass, and that later passes can be added
easily. It is one slick framework!




In case anybody is interested, I'll elaborate on what the point of
this transformation is. I'm looking at eager HTM systems like LogTM,
and in those, every transaction keeps track of the memory addresses
that it's read and written, at all times, and it detects memory
conflicts with other transactions immediately using the cache
coherence system. When one transaction conflicts with another,
sometimes one of the transactions can just stall while it waits for
the other one to finish. Other times, one of the transactions has to
abort and wait for a little while before it tries again. Stalls are
much cheaper than aborts, so we want to avoid aborting whenever we
can.


One bad scenario is very common: two transactions read the same memory
address, which is okay, then they try to write to it, which is a
conflict. There's no way they can get out of this just by having one
of them wait around, so one of them has to abort. It's terrible, but
what can you do? In benchmarks, this kind of memory access pattern is
common, and it slows LogTM (and related systems) way down. The only
good option is to avoid the situation in the first place: either
change the algorithm radically, which usually isn't an option, or
force one of the transactions to stall before reading the memory
address in question. That can be done by using read-with-intent-to-
write-later instructions, if you can just put them in. Which is fine
for people writing libraries of common data structures (hash tables,
etc.), but not an option for programmers who just want to get some
work done. Hence the desire for compiler support.


Anyway, I think your idea will work, so thank you.


-Peter

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