Re: measuring cached writes, was how do a RISC compiler ...

Sid Ahmed Ali TOUATI <Sid-Ahmed-Ali.TOUATI@inria.fr> writes:
> I thought that this is equivalent to access every X element in each
> iteration, which yield to some cache miss equal to 50 in an ultra
> sparc II.


Nope, stores are non-allocating on miss for UltraSPARC. Also, two of
them can be collapsed to one in the store buffer if they go to the
same cache sub-block.


> So: 1. is there a mechanism to store a constant value in a large
> data segment ? the code generated seems to contain classic stores
> ("st" instructions).


No.


> 2. Do the compiler bypass the data cache when it generate an array
> initialisation ? this is possible on some processors like the ultra
> sparc.


No. The hardware does. Using the BLD instruction you can also bypass
the cache on load, but no compiler does that yet.


> Remark: when I replace the instruction with x(i)=x(i)+1, a
> "relatively" correct number of cache misses is reported (42 or 43
> misses are reported). It proove that the compilation process is not
> the same for the first and the last version of the code despite the
> fact that I turned off all optimization options.


No it does not prove that. It proves that the compiler generates code
that first reads (generating the misses you see) and then stores the
data.




Achim Gratz.


-- +<[ It's the small pleasures that make life so miserable. ]>+ --
http://www.inf.tu-dresden.de/~ag7/ mailto:gratz@ite.inf.tu-dresden.de

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