From: cprice@mips.com (Charlie Price)
Newsgroups: comp.arch
Subject: Re: Code Repositioning on MIPS Systems?
Date: 30 Jul 1992 01:23:56 GMT
Organization: MIPS Technology, Inc
NNTP-Posting-Host: lloyd.mips.com

In article <32580130@hpcuhe.cup.hp.com> daryl@hpcuhe.cup.hp.com (Daryl Odnert) writes:
>Could someone please send me or post a high level description of
>the profile-based optimization capabilities of the MIPS compilers/linker.
>
>For example, I believe the MIPS system can support code repositioning
>based on application profile measurements to reduce I-cache misses
>and branch penalties.  Can someone verify this?  Any pointers to
>published documentation on these optimizations would also be appreciated.

There is a function rearranger named cord.
The idea is pretty simple: rearrange the functions in a program so
that program hot spots thrash less in the Icache.
To do this you make one or more runs of an application to find out
where the program spends its time and you use this information to
rearrange the program during a subsequent compilation.

Cord is normally invoked by the -cord option to cc or f77, but you
can get to the program directly if you like.
The manual page is included below for gory detail.





CORD(1-SysV)	    RISC/os Reference Manual	     CORD(1-SysV)



NAME
     cord - rearrange procedures in an executable file to facili-
     tate better cache mapping

SYNOPSIS
     cord [-v] [-o outfile] [-f] [-c cachesize]	[-p maxphases]
     obj_file reorder_file

DESCRIPTION
     The cord command rearranges procedures in an exectable
     object file to maximize efficiency	in a machine's cache.  By
     rearranging the procedures	properly, we end up reducing the
     instruction cache miss rates.  cord does not attempt to
     determine the correct ordering, but is given a reorder file
     containing	the desired procedure order.  The reorder file is
     generated by the ftoc program, which in turn generates a
     reorder file from a set of	profile	feedback files (see
     prof(1)).

     Processed lines in	the reorder file are called procedure
     lines.  Each procedure line must be on a separate source
     line.  Each procedure line	must contain the source	name of
     the file, followed	by a blank followed by a qualified pro-
     cedure name.  Nested procedures must be qualified x.y where
     x is the outer procedure.	A newline or blank can follow the
     procedure name:

     foo.c bar (everything else	following is ignored)


     Lines beginning with # are	comments, lines	beginning with $
     are considered cord directive lines. The only directive
     currently understood is $phase.  This directive will con-
     sider the rest of the file	(until the end of file or next
     $phase) as	a new phase of the program and will order the
     procedures	accordingly.  A	procedure may appear in	more than
     one phase,	resulting in more than one copy	of it in the
     final binary.  First, cord	will try to relocate procedure
     references	to a copy of the procedure belonging to	the
     requesting	phase; otherwise it will relocate the references
     to	a random copy.

     We	suggest	you use	the -cord option to a compiler driver
     like cc(1)	rather than execute cord directly.  cord options
     can be specified with -Wz,cordarg0,cordarg1,....  If you
     have to run cord by hand, you may want to run it once with
     the driver	using the -v flag on a simple program.	This will
     enable you	to see the exact passes	and the	arguments
     involved in using cord.

     Obj is an executable object file with its relocation infor-
     mation intact. This can be	achieved by passing the	-r -z -d



			 Printed 4/3/91			   Page	1






CORD(1-SysV)	    RISC/os Reference Manual	     CORD(1-SysV)



     options to	the linker, ld(1).  The	linker option -r main-
     tains relocation information in the object	file, but will
     not make it a ZMAGIC file (hence -z).  It also will not
     allocate common variables (hence -d) as it	would without the
     option.

     WARNING: Since cord works from an input list of procedures
     generated from profile output, the	resulting binary is data
     dependent.	 In other words, it may	only preform well on the
     same input	data that generated the	profile	information, and
     may preform worse than the	original binary	on other data.
     Furthermore, if the hot areas in the cache	don't fit well
     into one cachepage, performance can degrade.

     The cord command accepts these options:

	  -v   Print verbose information.  This	includes listing
	       those procedures	considered part	of other pro-
	       cedures and cannot be rearranged	(these are basi-
	       cally assembler procedures that may contain rela-
	       tive branches to	other procedures rather	than
	       relocatable ones).  The listing also lists those
	       procedures in the flipped area (if any) and a map-
	       ping of old location to new.

	  -f   Flip the	first cachepage	size procedures.  The
	       assumption when cord was	written	was that pro-
	       cedures would be	reordered by procedure density
	       (cycles/byte).  This option ensures that	the den-
	       sest part of each page following	the first
	       cachepage would conflict	with the least-dense part
	       of the first cachepage.

	  -c cachesize
	       Specify the cachesize (in bytes)	of the machine on
	       which you want to execute.  This	only affects the
	       -f option.  If not specified, 65536 is used.

	  -o outputfile
	       Specifies the output file. If not specified, a.out
	       is used.

	  -p phasemax
	       specifies the maximum number phases allowed. The
	       default is 20.

SEE ALSO
     cc(1), ftoc(1), ld(1), prof(1).
     RISCompiler and C Programmer's Guide






 Page 2			 Printed 4/3/91



-- 
Charlie Price    cprice@mips.mips.com        (408) 720-1700
MIPS Technology Inc. / 928 Arques Ave.  MS 1-03 / Sunnyvale, CA   94088-3650
Newsgroups: comp.arch