create new tag
view all tags

SloR Project


SloR is the integration of SLO (Suggestions for Locality Optimizations) and SLAT (Spatial Locality Analysis Tool). Both tools are used to analyze locality of programs and return feedback to the programmer on how to improve memory performance. It uses a modified version of GCC version 4.1.1 to collect information on individual accesses and then output the results into a .slor.zip file. Once output is created, a Java back end is used to display the results.

SLO was developed by Kristof Beyls at the University of Ghent. He has since left the University. A high level explanation of the tool can be found at http://escher.elis.ugent.be/publ/Edocs/DOC/P106_138.pdf. The acutual tool homepage is http://slo.sourceforge.net/.

SLAT was developed by Chen Ding, Chengliang Zhang, Xiaoming Gu and Tongxin Bai. Ding, Gu, and Bai are affiliated with the University of Rochester and Zhang is a member of Microsoft. A pending publication on the tool will be posted when it is released.

At the moment the actual code is NOT integrated.

Getting the code

Again, the code is not actually merged at this point. Soon, there will be a local svn repository with the project. For now, the code can be run individually. FYI, SLO contains the pretty Java back end.

- SLAT can be found on the compiler group repository.

- SLO can be found on sourceforge at http://sourceforge.net/projects/slo.

Getting the code to run (individually and at the moment)

Building the tools is not difficult. Following the readmes in the downloads should make this simple enough. Unfortunately, both tools require their own versions of GCC. Consequently, each version of GCC will have to be built. This takes a long time. Typically, SLO will cause a slowdown of about 8 and SLAT will have one around 350. A sampling method is being developed to make SLAT faster (at the moment, it collects all data accesses).

The general structure of SLAT is relatively straightforward. Basically, its version of GCC will just insert method calls to an external file at reads and writes. The control flow of running the analysis is as follows: First, its modified version of GCC is used to create .o files (with the -ftrace-dep flag). Next, the files are linked together with the reda.o (from reda.cxx in the reda file). Finally, the new executable must be run.

The structure of SLO is very different from that of SLAT. Its version of GCC is highly modified compared to that of SLAT. Its code is actually built in to GCC as opposed to SLAT. Its fuller integration naturally makes the program a little faster, but also hurts the codes modularity. After an executable is created with the new GCC, a .slo.zip output file with the analysis information is created in the working directory. The control flow of running the analysis is as follows: .slo_instr_o files are created (they are .o files with a little extra) through the modified GCC. Next, these files are linked together in to an executable. When this program runs, it creates a BRD file and several other files for each source file. Zipping the BRD files, source files, .bb_info files, .memaccess_info files and the .function_info files creates the target .slo.zip file.

Both of SLO and SLAT rely on makefiles to analyze the code. Unfortunately, there is not an easier way of doing this due to the complexity large program compilation. Below are two sample makefiles for getting the spec2006 mcf program to run.

More on SLO's code

SLAT makefile

CC = /u/ichrist2/Research/gcc-slat/slat/BinDir/bin/gcc

CXX = /u/ichrist2/Research/gcc-slat/slat/BinDir/bin/g++

REDA_LIB = /u/ichrist2/Research/gcc-slat/slat/reda/reda.o

OPT = -O3

REDA = -ftrace-dep

#Fill in these

COBJECTS := implicit.c mcf.c mcfutil.c output.c pbeampp.c pbla.c pflowup.c psimplex.c pstart.c readmin.c treeup.c

TAR := mcf

#These created for you


SOURCE := $(TAR).c

MID := $(TAR).o

all: reda-out clean: rm *.o

%.o: %.c $(CC) $(OPT) $(REDA) -c -o $@ $<

reda-out: $(OBJECTS) $(CXX) $(OBJECTS) $(REDA_LIB) -o $(TAR);

SLO Makefile

CC = $(HOME)/gcc-slo/bin/gcc-slo

CCC = $(HOME)/gcc-slo/bin/g++-slo

INSTR_FLAG = -O3 -fno-inline -fslo-instrument

INSTR_LINK_OPTIONS = -static -lrd


COBJECTS := implicit.c mcf.c mcfutil.c output.c pbeampp.c pbla.c pflowup.c psimplex.c pstart.c readmin.c treeup.c

PARAMETER := ../data/train/input/inp.in

EXECUTABLE := mcf_slo_instr


all: mcf mcf.slo.zip

clean: rm *.slo_instr_o *.o mcf mcf_slo_instr *_info BRD mcf.slo.zip

%.slo_instr_o: %.c $(CC) $(INSTR_FLAG) -c -o $@ $<

%.o: %.c $(CC) -O2 -c -o $@ $<

mcf: $(OBJECTS) $(CC) -o $@ $(OBJECTS) -lm

mcf_slo_instr: $(IOBJECTS) $(CCC) -o $@ $(IOBJECTS) $(INSTR_LINK_OPTIONS) -lm


mcf.slo.zip: BRD zip $@ BRD $(foreach cur,$(COBJECTS), $(cur) $(cur).bb_info $(cur).function_info $(cur).memaccess_info)

-- IanChristopher - 27 May 2008

CSC290A Project 1 CSC290A Project 2

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2009-02-14 - IanChristopher
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback