RALF's FAQ
Known
Bugs
Q: I have a function that initializes an integer array. The output I
get
by running the a.out is not what's expected.
A: This is a bug in the gcc base that is being used. This will go away
once RALF is ported to the latest gcc.
Frequently Asked
Questions:
Q: How does the framework interact with the framework?
A: RALF outputs a specification of the input program and the target
architecture as a MIRA program in
the $ILP_IN file. And then the framework invokes the register allocator
specified by the environment variable ILP_SOLVE. The framework expects
the output of register allocator in FORD
format in the file $ILP_OUT. The framework checks the exit status of
the register allocator. If the allocator has failed, then framework on
a default register allocator and continues with compilation. The status
of the fallback is given as a statistic.
Q: I do not want certain functions to be compiled by my register
allocator. Is there a way out?
A: Yes! Create a file .ignore_files in the directory from which the
compiler is being invoked and include the function names that needs to
be excluded. The compiler will invoke the default gcc register
allocator.
Q: What's the meaning of the message: 'RA failed. Invoking the default
RA'?
A: It means that the register allocator provided failed for certain
function and RALF has invoked the gcc's default register allocator.
Q: Why do I get a bunch of Warnings?
A: These warnings indicate possible conflicts within the maps output by
the plugged in register allocator at the marked instruction number.
Q: Can I ignore these warnings?
A: Yes, you can. RALF can generate code in the presence of these
warnings.
Q: What about the "Errors"? Can I proceed without fixing those?
A: No. RALF cannot proceed with those errors. You have to fix them.
Q: Can I provide my own set of "available registers"?
A: Not yet. The current release Ralf-0.1 does not yet support that. The
next release will mostly support this.
Q: What are different values that can be given to the environment
variable DO_SARA?
A: DO_SARA can be 1, 2, or 3. If you are doing register assignment and
spill code generation and no stack location then you would mostly want
to set it to 2 only. This variable affects the liveness information
given by the framework. A value of 2, results in generation of precise
liveness information. A value of 1, makes liveness of each pseudo
that is used in a basic block to extend from the beginning of the basic
block till the point of it's death. A value of 3, makes the liveness of
each variable extend to a point that is two instructions before the
current instruction. For example in the following basic block:
i1: b = use a ; a dies
i2: c = use b ; b dies
i3: d = use c ; c dies
i4: use d ; d dies
If DO_SARA is set to 2, then a is
live in i1, b is live in i2, c is live in i3, and d is live in i4. If DO_SARA is set
to 1, then a is live in i1, b is live in i1 and i2, c is live in i1, i2, and i3, and d is live throughout. If DO_SARA is
set to 3, then a is live in
i1, b is live in i1 and i2, c is live in i1, i2, and i3, and d is live in i2, i3, and i4.
Q: My target is Big-endian, what should I do?
A: Add the switch -mB to your compiler and linker.
Q: I have used RALF on XYZ platform. But it needed some modification to
installation scripts and some files. How can share my experience with
others?
A: Please send all those details to the author and the webpage will be
updated after going through your suggestions.