urcodeboijorto574 / compilers-ntua Goto Github PK

A function that is not defined/declared in the local definitions of a function can't be called in its block. This happens because each function is accompanied with a stack frame pointer which, in this case, is not set correctly. An error message for this occasion is shown below:

llc: error: llc: a.ll:131:13: error: '@a' defined with type 'void (%frame_main*, i64)*' but expected 'void (%frame_cirr*, i64)*'
  call void @a(%frame_cirr* %stack_frame_cirr, i64 0)

In the example above, 'a' and 'cirr' functions are defined in the local definitions of 'main' function and in the block of 'cirr' function 'a' is called. So, a search happens for 'a' function using the stack frame pointer that points to 'cirr' and the search fails.

A structure "if-then-else-if-then-else-..." doesn't produce the IR code expected.

A structure while ... do { while ... do ... } doesn't work as well.

When these statements have simple statements in their blocks, such as assignments and function calls, everything works as expected.

writeString("Hello World!!!\n.This is my first grace program.").
This line should print two lines, however only one is printed. Perhaps we should check the lexer.

Currenlty lvalues have not semantics behind them, they are just ids, so when we want to gen an lvalue address we do not know if this lvalue is a variable reference. One solution would be to change the Ast and the Parser but it will need a refactor. Temp solution is to add a third field to variables records of each function, holding if the variable is a reference (pointer) or not.

If a function returns a value only inside an if-then-else statement, in the merge basic block that the LLVM builds by default a "ret void" instruction is put. This concludes to a type error.

Currently, the error messages the the compiler prints are very generic.
Each error message should include the following information:

• Type of error: lectic, syntactic or semantic error
• Line and column number
• Detailed Message so that the way the error is fixed is graspable.

llc: error: llc: a.ll:412:3: error: instruction expected to be numbered '%4'
%3 = call i64 @iPow(%frame_triangle* %access_link_ptr9, i64 %x6, i64 %subtmp)

We cannot have in the else branch both ret and br statements. We must have only one and at the end.
Line 415: ret i64 %multmp
br label %if_then_else_cont

Here we must have only one of these

llc: error: llc: a.ll:205:7: error: value doesn't match function result type 'i64'
ret void
^
clang: error: no such file or directory: 'a.s'

If i put ret i64 0, the program works as expected

When the executable file a.out is ran, it returns some non-zero values, whether it ran successfully or not.
It is important that the return value of a successful execution is 0 and non-zero otherwise.

Currently, when generating the LLVM IR code the conditions are always evaluated, and the result is not short-circuited.

When haveing a ret statement followed by a branch statement in if-then-else and while, we get this error from llvm:

Terminator found in the middle of a basic block!
label %while

This causes the optimizations to be corrupted and not working as expected.

If the main function of a program is not named "main" then the IR can't be generated. Syntactically and semantically there's no problem.

The following example results in an infinite loop when in generation of IR:

fun main() : nothing
  var errorValue : int;
  fun sum(x, y : int) : int
    fun incrByStep(a, step : int) : int {
      if 1 < 0 then return errorValue;
      else          return a + step;
    }
  { return incrByStep(x, y); }

{
  errorValue <- -1;
  writeString("1 + 2 = ");
  writeInteger(sum(1, 2));
  writeChar('\n');
}

_{Note: the infinite loop happened when encountered the lvalue 'errorValue' in line 5.}