Recently, the foundation put forth
a specification for HSAIL (HSA Intermediate Language), which is positioned as the ISA of a HSAIL virtual
machine for any computing device
that plans to adhere to the standard.
HSAIL is quite low level, somewhat
analogous to the assembly language
of a RISC machine. It also assumes a
specific program and memory model
catering to heterogeneous platforms
where multiple ISAs exist, with one
specified as the host. It also specifies
a model of parallel processing as part
of the virtual machine.
Although HSAIL is aligned with the
vision of enabling a software ecosystem based on a virtual machine, its
requirements are too strong and lack
generality, and thus will limit its applicability to the specific segment of
the computing industry that it targets.
Though HSAIL serves as the compilation target for compiler developers,
it is unlikely that any compiler will
adopt HSAIL as an IR during compilation because of the lack of simplicity
in the HSAIL virtual machine. It is a
step in the right direction, however.
iR Design attributes
In conclusion, here is a summary of
the important design attributes of
IRs and how they pertain to the two
visions discussed here. The first five
attributes are shared by both visions.
˲ Completeness. The IR must provide clean representation of all programming language constructs, concepts, and abstractions for accurate
execution on computing devices. A
good test of this attribute is whether it
is easily translatable both to and from
popular IRs in use today for various
˲ Semantic gap. The semantic gap
between the source languages and the
IR must be large enough so that it is
not possible to recover the original
source program, for the sake of intellectual property rights protection.
This implies the level of the IR must
˲ Hardware neutrality. The IR must
not have built-in assumption of any
special hardware characteristic. Any
execution model apparent in the IR
should be a reflection of the program-
ming language and not the hardware
platform. This ensures it can be com-
piled to the widest range of machines,
and implies the level of the IR cannot
be too low.
˲ Manually programmable. Programming in IRs is similar to assembly programming. This gives programmers the choice to hand-optimize
their code. It is also a convenient feature that helps compiler writers during compiler development. A higher-level IR is usually easier to program.
˲ Extensibility. As programming
languages continue to evolve, there
will be demands to support new programming paradigms. The IR definition should provide room for extensions without breaking compatibility
with earlier versions.
From the compiler’s perspective,
there are three more attributes that
are important considerations for the
IR to be used as program representation during compilation:
˲ Simplicity. The IR should have as
few constructs as possible while remaining capable of representing all
computations translated from programming languages. Compilers often perform a process called canoni-calization that massages the input
program into canonical forms before
performing various optimizations.
Having the fewest possible ways of
representing a computation is actually good for the compiler, because
there are fewer code variations for the
compiler to cover.
˲ Program information. The most
complete program information exists
at the source form in which the program was originally written, some of
which is derived from programming
language rules. Translation out of
the programming language will contribute to information loss, unless
the IR provides ways of encoding the
escaped information. Examples are
high-level types and pointer aliasing
information, which are not needed for
program execution but affect whether
certain transformations can be safely
performed during optimization. A
good IR should preserve any information in the source program that is
helpful to compiler optimization.
˲ Analysis information. Apart from
information readily available at the
program level, program transforma-
tions and optimizations rely on addi-
tional information generated by the
compiler’s analysis of the program.
Examples are data dependency, use-
def and alias analysis information.
Encoding such information in the IR
allows it to be usable by other compil-
er components, but such information
can also be invalidated by program
transformations. If the IR encodes
such analysis information, it needs to
be maintained throughout the compi-
lation, which puts additional burdens
on the transformation phases. Thus,
whether or not to encode informa-
tion that can be gathered via program
analysis is a judgment call. For the
sake of simplicity, it can be left out or
A standard for a universal IR that
enables target-independent program
binary distribution and is usable internally by all compilers may sound
idealistic, but it is a good cause that
holds promises for the entire computing industry.
All Your Database Are Belong to Us
Progammability and Efficiency
William J. Dally, Ujval J. Kapasi, Brucek
Khailany, Jung Ho Ahn, and Abhishek Das
Software Development with Code Maps
Robert DeLine, Gina Venolia, and Kael Rowan
1. barron, d.w. (ed.). Pascal–The Language and its
Implementation. john wiley, 1981.
2. Common Intermediate language (CIl); http://
3. Cuda; http://www.nvidia.com/object/cuda_home_new.
4. hmPP; http://www.caps-entreprise.com/openhmpp-directives/.
5. hsa foundation; http://www.hsafoundation.com/.
6. java bytecode; http://www.javaworld.com/jw-09-
7. jVm languages; http://en.wikipedia.org/wiki/list_of_
8. openCl; http://www.khronos.org/opencl/.
9. open source compilers; http://en.wikipedia.org/wiki/
Fred Chow ( firstname.lastname@example.org) pioneered the
first optimizing compiler for rIsC processors, the mIPs
ucode compiler. he was the chief architect behind the
Pro64 compiler at sgI, later open sourced as the open64
compiler. he later created the widely accepted Pathscale
version of the open64 compiler. he is currently leading the
compiler effort for a new processor at ICube Corp.
© 2013 aCm 0001-0782/13/12 $15.00