modeler returns "maximum code size exceeded" or "4712 expected between -4096 and 4095" if code size is increased about selfie HOT 7 OPEN

I briefly looked into the third error you described in your issue (i.e. expected between -4096 and 4095). This is most likely some if-statement with a very large body in modeler.c exceeding the hard limit of 2^12 - 1 for the immediate of a beq instruction.

Quickly adding some statistics I saw that an unmodified version of selfie hits a maximum (positive) immediate of 3856 when compiling modeler.c. This is already pretty close to the limit and doesn't give much wiggle room for someone with local modifications to the compiler that increases the size of code within the body of that if-statement. I assume you have such modification in your version of selfie? For comparison, self-compiling selfie.c with selfie only reaches a maximum (positive) immediate of 2524 at the moment.

I can try to look through modeler.c and see if some large if-statement can somehow be rewritten to increase this wiggle room. But in general this hard limit on beq is something one can always run into, or provoke/trigger on purpose.

Just as a side-note: What production compilers usually do is to rewrite a simple beq in some way when they detect such an overflow occurs (or might occur). This however increases complexity of code generation, and is especially troublesome for single-pass compilers like selfie. So it is presumably not suited for being added into selfie. The following is one example for such a rewrite:

Rewrite this (beq has an immediate limit of 2^12 - 1):

beq t0,zero,#offset

Into the following form (jal has an immediate limit of 2^20 - 1):

bne t0,zero,2
jal zero,#offset

from selfie.

@mstarzinger Thanks for looking into it.
You are right, I modified my selfie implementation to support all compiler assignments.

I went through my selfie.c and the biggest if-statement is the one of get_symbol with around 400 lines of code inside the outmost if. Others where around 200 lines or less. I went ahead and moved some inner code into methods, reducing the if-statement to about 200 lines.
However, I still get the same error and even the number of 4492 expected between -4096 and 4095 remains the same.

I looked at the assembler code of selfie with -s and the biggest offset of a beq instruction was at 1000 (which was get_symbol()) and after refactoring, I got it down to some beq having an offset of about 600.

I am not familiar with modeler, but is it possible to better debug at which beq it fails?

Also: How does the offset scale? I thought the biggest offset is the one from the first if to the end of else. Which means that else if between increases the offset, but method calls do not (or not that much).

Thanks for your help!

from selfie.

After refactoring get_symbol() with no change to the error message, I went and stepped through all fixup_relative_BFormat calls and found that the problem is not from an if-statement but from a while-loop.
(The fixup call at the end of compile_while throws the error)

So I went through all while-loops searching for the largest one (looking in selfie.c and modeler.c).
I found the biggest one in modeler.c starting at line 2000 for 139 lines (The output is even mentioning line 2140 for the error I get with my modified selfie.c).

After moving two parts of around 30 lines each out of the loop, make mod runs without errors.
selfie still self-compiles and the implemented assignments pass.

Note: I copied everything outside the loop passing needed parameters, so the logic remains the same.

Which leaves me with the question: Why is modeler.c failing for me, but not in the original selfie with the larger while?

from selfie.

@mhatzl Nice, thanks for digging further into this. Good to know which while-loop is the culprit (and the fact that it is a while-loop instead of an if-statement).

Regarding your last question: Some of the changes in your version of selfie are likely increasing the amount of code (i.e. number of RISC-V instructions) that are emitted for certain expressions/statements that appear within this loop's body. This increases the distance that beq has to cover when jumping over (and skipping) the loop. So even though the number of source lines within the loop in modeler.c is the same in the original and in your version, the size of the emitted code for these lines increases. At least that is my working theory.

from selfie.

@mstarzinger Thanks for your explanation.

Do you want to dig further into this issue to find out what expression/statement is the problem? (I can not make my repository public, but I think I am allowed to give you access if you want to)

Otherwise, I will keep my adaptation of modeler.c. I do not know what the code is doing in modeler.c, so my naming for the created functions is quite terrible, but if you want, I can create a pull request or post the modified loop here.

from selfie.

@mhatzl I have in the meantime also refactored the while-loop in question in modeler.c a bit. I checked that it reduces the maximum (positive) beq distance down to 2524 (same as in just selfie.h without modeler.c). It would be great if you could verify that this indeed fixes the problem on your end as well. If so, then I'll make a PR out of it.

My proposed change is here: https://github.com/mstarzinger/selfie/tree/refactor-modeler-control-flow

from selfie.

@mstarzinger I have tested your implementation and make mod runs without error.

Thanks again.

from selfie.