Fix problem where long basic blocks could lead to a crash due to stack overflow in common subexpression elimination.

The issue was that one of the procedures used for CSE would recursively call itself for every 'next' link in the code of the basic block. To avoid this, I made it loop back to the top instead (i.e. did a manual tail-call elimination transformation).

This problem could be observed with large switch statements as in the following example, although other codes with very large basic blocks might have triggered it too. Whether ORCA/C actually crashes will depend on the memory layout--in my testing, this example consistently caused it to crash when running under GNO:

#pragma optimize 16
int main (int argc, char **argv)
{
    switch (argc)
    {
        case 0:  case 1:  case 2:  case 3:  case 4:  case 5:  case 6:  case 7:
        case 8:  case 9:  case 10: case 11: case 12: case 13: case 14: case 15:
        case 16: case 17: case 18: case 19: case 20: case 21: case 22: case 23:
        case 24: case 25: case 26: case 27: case 28: case 29: case 30: case 31:
        case 32: case 33: case 34: case 35: case 36: case 37: case 38: case 39:
        case 40: case 41: case 42:
        case 262:
        ;
    }
}
This commit is contained in:
Stephen Heumann 2016-11-21 17:43:45 -06:00
parent 896c60d18c
commit aa7084dada

10
DAG.pas
View File

@ -2562,8 +2562,10 @@ var
{ start - has op1 been found? (initialize to false) }
{ stop - has kill been set? (initialize to false) }
label 1;
begin {Scan}
if not start then {see if it is time to start}
1: if not start then {see if it is time to start}
if list = op1 then
start := true;
if list^.left <> nil then {scan the children}
@ -2607,8 +2609,10 @@ var
stop := true;
end; {if}
if not stop then {scan forward in the stream}
if list^.next <> nil then
Scan(list^.next, op1, op2);
if list^.next <> nil then begin
list := list^.next;
goto 1;
end; {if}
end; {Scan}