1. The first phase is Whirl profiling instrumentation. An example of the compiler options used is shown below:

     "-O3 -ipa -fb_create fb.mid -fb_type=1 -fb_phase=0 "

    After linkage, run the application with "train" input data set. It'll generate whirl feedback files with names like fb.mid.instr0.aginqw.

2. The second phase involves whirl  profiling annotation, stride profiling instrumentation and edge profiling instrumentation, e.g.,

    "-O3 -ipa -fb_opt fb.mid -fb_create fb.mid -fb_type=10 -fb_phase=4"

    After linkage, run the application with "train" input data set. It'll generate feedback files with names like fb.mid.instr0.01324, which

    combine the information obtained by edge profiling and stride profiling.

3. The last phase uses all the profiling information collected and turns on all optimizations, e.g.,

    "-O3 -ipa -fb_opt fb.mid"

    For further optimization opportunities, you may use -OPT:Olimit=0 as described above.
         

Are there documents that come with the compilers?

We  have  included  in the release some documents related to our added  features  and  optimizations.  More will be coming. The documents will  mostly   be   in   the   code   generator   area,   related   to   our  changes/additions. For documents related to Pro64, please refer to the publication  list.  Those  marked  with  *  in the list reflect actual  implementation in various components of the compilers. We  have  also  done  three  tutorials  in  the past two years. Two in Micro34  and  Micro35,  one  in PACT02. Each tutorial covers different aspects of the compiler. You can find the tutorial material in the ORC site in sourceforge.

Interactions of ORC and IA-64 Linux Questions

How do I install ORC compilers on IA-64 Linux systems?

The  binaries  are  packaged  in  tar-ball  form. Just untar the file downloaded,  run  the  script "install-bin.sh". Help manual of this script is:

             
To install compiler on IA-64 Linux system, simplily by invoking ./install -n.
The environment variables $TOOLROOT will affect installation as well as orcc's  run-time behavior. $TOOLROOT refers to root  for the binary hierarchy of ORC suite.  For example, if this variables is not set, the full path of orcc is /usr/bin/orcc (it obviously  requires root proprietary), otherwise, ${TOOLROOT}/usr/bin/orcc.
 

  If $TOOLROOT is set, you need to add $TOOLROOT/usr/bin/ to $PATH.
 

  Following are 2 installation examples:
 

Please note that the binary in orc-2.0-bin.tar.gz is prepared for RedHat 7.2 Linux system. Some users experienced certain problems when installing RedHat 7.2 on Itanium I machines. Our test shows the compiler works fine on successfully installed machines.

How do I install ORC compilers on IA32 Redhat 6.2 Linux systems?

Sometimes it's desirable to install the compilers on IA32 machines and do cross compile on  a  bare  Linux  6.2 box. In this case you can use NUE, an Itanium simulation environment, to get  a "virtual native IA64 system" on IA32.

       
    1. Download NUE from HP website and install it.
    2. After installing NUE,  you might need to re-link following 2 folders (depending on your
        NUE version number) to make orcc  also workable outside  NUE. 
 
        if /nue/usr/include/asm is a  symbolic link then change it to /nue/usr/src/linux/include/asm, by:

              cd /nue/usr/include

              rm asm
              ln -s  /nue/usr/src/linux/include/asm  asm 

        if /nue/usr/include/linux is a symbolic link then change it to /nue/usr/src/linux/include/linux/,  by:

                cd /nue/usr/include
                rm linux
                ln -s /nue/usr/src/linux/include/linux/ linux

     3.  Download  gcc (we only used 2.95.2 release and 2.96), and then
                configure --prefix=/usr;  make all install

            and then do a gcc -v to make sure you have the right version.

      4.  You don't need to build the binary at this point, just install that from the download.
  
    To build cross environment, keep in mind a number of things:
        1.  The  NUE environment is a simulated IA64 system on top of the IA32 Linux box. However, we do not need to enter NUE to perform cross compilation. 

        2. ORC relies on NUE's cpp (C PreProcessing) functionality as well as its native header files. Therefore NUE is an essential setup for cross compilation.
        3. By entering "nue", you are switched to a simulated native box. But  you need not do so for cross compilation.
        4. From  the IA32 Linux box, your file structure is really under  /nue.
        5. To do cross compile, do ${TOOLROOT}/usr/ia64-orc-linux/bin/orcc file.c. NOTE: The path for cross orcc is a little bit different from that of the native one, i.e., "ia64-orc-linux" is interposed between "/usr" and "/bin"

How do I install ORC compilers on IA32 Redhat 7.1 Linux systems?

orc-2.0-bin.tar.gz is not workable on this platform due to the shared object compatibility problem. A cross compiler on a 7.1 system is possible, you need to build that from the source tree.

How do I install ORC compilers on IA32 Redhat 7.2 Linux systems?

For  IA32  system  with Redhat 7.2 installed, the ORC compiler will be  used as a cross compiler. We have provided a script     INSTALL.cross that  will  install  the  compiler  binaries.  The  binaries are packaged in  tar-ball  form.  Just  untar  the  file downloaded,  run  the  script  "install.sh -c". We recommend the users install NUE 1.1 on RedHat 7.2 or higher. Since  NUE 1.0 does not run on this system, you will be doing strictly cross compilation in  this case.

How do I make a native built compiler?

We have provided a sample makefile (Make.native) in the same directory  as  Make.cross.  Simply  do  a  make  with Make.native.

How do I install multiple versions of ORC compilers on IA-64 systems?

Sometimes it's desirable to install multiple versions of the compilers on a machine, for debugging or experimental purposes. Assuming you have two different versions of ORC compiler binaries, installed in different directories, simply set the environment variables TOOLROOT and COMP_TARGET_ROOT to point to the directories for the desired binary and archives and it should work.

How do I rebuild the Fortran front-end?

     The Fortran front-end (i.e., mfef90) will not be built by default. If you want to rebuild it, you need to install the ORC binary first.

     Then do the following:

        cd ${ORC_SRC_ROOT}/src/osprey1.0/targia64_ia64_nodebug/crayf90/sgi; make BUILD_COMPILER=SGI

If I do cross compile on an IA32 machine, how do I produce IA-64 binaries?

In order to pick up the right set of archives or dynamic shared libraries, the simplest way is to produce object files in cross compilation, copy the objects to the target IA64 systems and do the final link there to produce the binary, as follows:

1. At IA32 side:

  [IA32]% orcc  –c hello.c –o hello.o

  [IA32]% ftp IA64                                         (transfer hello.o to an Itanium machine)

2. At IA64 side:

  [IA64]% orcc hello.o –o hello

  [IA64]% ../hello

  hello world!

  %

ORC 2.0 release allows you to produce IA64 binary on IA32 machines directly. Simply follow the install instructions to set the environment variables and install the pre-built native archives properly.

Reporting bugs and problems

Where do I report bugs?

We cannot promise to fix every bug reported. If you think that you have uncovered a bug in the ORC compilers, you can post that to ipf-orc-support@lists.sourceforge.net. We will do our best if the bug is found to be ORC specific. For Pro64 specific bugs, we encourage you to post the problem in open64-devel@lists.sourceforge.net. 

How do I decide if the bug is ORC specific?

Our changes are primarily in the code generator area. To find out if the problem you have is specific to code due to our changes:

If the bug persists at –O0 level, it is likely Pro64 specific.

Otherwise, add “-CG:opt=0” and if the bug persists, it is most likely not in the code generator area

Otherwise, add “-ORC:=off” and if the bug goes away, the bug is ORC related.

How do I report bugs?

You can help us quickly turn around the fixes by doing some up front work. 

Minimize the test cases. Provide a fully preprocessed file (-E option) to avoid dependence on specific header files.

Give us a full command line description to compile the tests.

Tell us how to run your program if the symptom occurred at runtime. If the program needs data input, please append it as well.

You can even help by utilizing the triage tool we provided to narrow down the optimization, procedure and BB/region/instruction that is showing the problem.

Using tools that come with the compiler

How to use hot path enumeration tool?

How to use cycle counting tool?

The cycle counting tool(cycount.pl) can be used to count the cycle number of hot functions in SPEC2KINT benchmarks. It's suitable for statically investigating ORC performance degradation. It works on SPEC2KINT assembly files generated by ORC.
 

Adding new optimizations or phases

Are there any coding conventions?

Please find the coding convention guideline here. This guideline is designed to stay close to the Pro64 coding style and convention. You can also find documentation on how the compiler handles memory management and various other issues.

How do I add my own tracing options?

One can have either summarized or detailed trace of any specific optimization performed. The traces are dumped to the file xxx.t where xxx.o is the desired output object file. To add your own tracing options, do:

1. Make sure what you want to add is a phase-specific trace flag. Assume your phase is XYZ (a corresponding number xyz can be found in osprey1.0/common/util/tracing.h). It will be used like this:

    -Wb,-ttXYZ,0xnn

    ( -Wb,-ttxyz,0xnn is the same )

2. Modify xyz_defs.h to define your flags

    (the minor number above, nn. The major number is mm. ).

    Please add them in the end.

3. Your code using these flags should be like:

      if (Get_Trace(TP_XYZ, YOUR_FLAG)) {

           YOUR_CLASS.Print(TFile);

      }

   where Tfile is the file handle of the trace file.

4. common/util/tracing.h is the file of interest to add tracing.

How do I change the driver and related files when I add an optimization?

When you add your phase in the compilers, the following issues are important:

1. Suppose you want to add a phase inside the code generator

2. All files you want to add should have lower-cased file names, with words separated with underscore, such as: if_conv.cxx.

3. You should define (declare) a flag in cg_flags.cxx(.h) controlling whether your phase should be run.

4. You should add an element in arrary Options_IPFEC in cgdriver.cxx describing your flags.

    There are already several flags there, you can take them as examples.

5. Your flags should have prefix: IPFEC_Enable_XXX, such as IPFEC_Enable_If_Conversion.

    At least, they should have prefix: IPFEC_XXX.

6. For other components, they are all similar. The files common/com/xxx_config.h and common/util/flags.{h,c} are files of interest. 

How do I effectively use gdb for debugging the compiler?

Pre-requirements:

1. Your gcc version needs to be 2.95.2 or 2.96

2. To enable debugging, you can build the entire compiler with

    make BUILD_OPTIMIZE=DEBUG

    Or you can build individual components (such as wopt.so) by going into the corresponding targia_xxx directories, and build with "BUILD_OPTIMIZE=DEBUG".
 

To single step inside the backend components (we'll show the CG portion, other components are similar): 

1. Remember to set the environment variable LD_LIBRARY_PATH. 

       For cross compiler this variable should be set as
           export LD_LIBRARY_PATH=${TOOROOT}/usr/ia64-orc-linux/lib/gcc-lib/ia64-orc-linux/2.0:$LD_LIBRARY_PATH

       For native compiler it should be 

           export  LD_LIBRARY_PATH=${TOOROOT}/usr/lib/gcc-lib/ia64-orc-linux/2.0:$LD_LIBRARY_PATH

2. First run orcc using options " ... -show -keep ... ". It will keep some needed intermediate files. 

   orcc -show -keep kk16.c

   It will print some info like this:

               /home/xyz/orc-2.0/usr/ia64-orc-linux/altbin/gcc -D_LANGUAGE_C -D_SGI_COMPILER_VERSION=10. -D__host_ia32 -D__INLINE_INTRINSICS -D_LP64 -D__ia64=1 kk16.c -E > kk16.i

               /usr/ia64-orc-linux/lib/gcc-lib/ia64-orc-linux/2.0/gfec -O0 -dx -quiet -dumpbase kk16.c kk16.i -o kk16.B

               /usr/ia64-orc-linux/lib/gcc-lib/ia64-orc-linux/2.0/be -PHASE:c -G8 -O0 -TENV:PIC -m1 -INTERNAL:return_val=on -INTERNAL:mldid_mstid=on -INTERNAL:return_info=on -show -TARG:abi=i64 -LANG:=ansi_c -fB,kk16.B -s -fs,kk16.s kk16.c

               Compiling kk16.c (kk16.B) -- Back End

               Compiling main(0)

               /usr/ia64-orc-linux/bin/as kk16.s -o kk16.o

               /usr/ia64-orc-linux/bin/ld -dynamic-linker /lib/ld-linux-ia64.so.2 -rpath-link ...

            3. Now we can use the input file and options for BE as the input to gdb when debugging BE:

                gdb /usr/ia64-orc-linux/lib/gcc-lib/ia64-orc-linux/2.0/be

                (gdb)break be_debug

                (gdb)run -PHASE:c -G8 -O0 -TENV:PIC -m1 -INTERNAL:return_val=on -INTERNAL:mldid_mstid=on -INTERNAL:return_info=on -show -TARG:abi=i64 -LANG:=ansi_c -fB,kk16.B -s -fs,kk16.s kk16.c

            4. After gdb stopped, set another breakpoint and trace into the component that you are interested in.

How do I make sure my new phase is not the cause of unnecessary long compile time?

All optimization phases are timed by the compiler for ease of measurement. Please make your phase timed also.

It's simple and you only need to add two lines in your code, one after entering your phase, for example:

    Start_Timer(T_Aurora_LOCS_CU);

and another before leaving your phase, for example:

    Stop_Timer(T_Aurora_LOCS_CU);

and remember to include timing.h in your code.

Naturally, you'll need to define your timing phase, please look at file be/com/timing.h.

After re-compiling, you can get timing info using -Wb,-ti1.