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.