🚀 go-pugleaf

Hello gnu helpers,


I'am trying to configure gcc for a processor which has been
developed here. The processor is a bit different of the "normal"
processors, in the sense that it can only execute a straight
sequential block of code. In other words, it only has arithmetic
and move operations. This is no really problem because the
class of problems we want to run can be flattened in a straight
piece of C or assembly code, as they only use fixed limits loops
and if-then-else or case statements with conditions which value
is known at compile time. I have two problems concerning
this task that I can't solve. I don't know if this is the
right place to ask for help, neither if the things I want can
be done in any way. I hope someone can help!


1. Combination of insns

First of all, I want to combine insns into sequences of
two operations like y=a+b*c, y=a-b*c, etc. I found
one configuration file (arm.md) which has exactly these
insn definitions (actually, there is only the mul-add
combinations). These definitions work fine, but they
require all the operands in registers. I then changed
the operand predicates in the insns that define the
combination of instructions, and in the definitions of
the four arithmetic operations, to accept any operand
(general_operand), and using "rmi" as all the operand
constraints (except for the lvalue of expressions).
The problem is as follows:

With all the four artihmetic operations defined
with the same predicates and constraints (to accept
any kind of operator), and the insns for each
combination of mul/div and add/sub defined in the same way,
the compiler hangs (even for a C program with only a empty
function) and crashes (after 4 ou 5 minutes on a SPARCstation 2)
with the message:

gcc-cross: Internal compiler error: program cc1 got fatal signal 4

After many compilations, I found that the reason for that 
is ONLY the definition of the combination of MUL and ADD
operations. Deleting them, ALL the other definitions
work fine, and the compiler catches all the sequences
MUL-SUB, DIV-ADD and DIV-SUB correctlly, allowing any kind
of operand (register or memory). As the arm.md example 
uses exactlly the MUL-ADD combination, but with
the operands in registers, I then tryed that, ignoring
all the other definitions for the combine phase. And 
with the operand predicates allowing only registers, it works!
However, that requires that the add and multiply insns must accept
only register operands, which is not our case.

The big question is: Is there anything special about the
combination of multiply and add operations that make necessary
to have its operands in registers?


2. Loop unrolling and constant propagation

The second problem is related to loop unrolling and constant propagation.
I have a loop with a constant final value, and within the loop there
are if-then-else and switch-case statements, but using only a
conditional and switch expression that can be calculated as a constant 
at compile time, depending only on the loop control variable.
As an example (this is not a real example!):


	for(i=0; i<10; i++)
	{ a = b[i] + k * l[i];
          switch(i)
	  { case 2 : b[i] = k * b[i];
		     break;
	  /* and more cases... */
 	  }
	  if ( i>6 ) l[i] = -l[i];
        }


I have redefined the MAX_UNROLLED_INSNS, to force the loop unrolling
independently of its size. Sometime it works fine and the final code
has no jumps. But that depends on the number of statements, number
of cases and the existence of the else clause in if statements. Is there
any way to force the simplification of all the comparisons between 
compile time constants?

If you have any hints about this, please send e-mail. Any help
will be appreciated.

Thanks in advance

Jose'

-----------------------------------------------------------------------
Jose Carlos Alves (Guest Researcher)  | PHONE : (49) 6151 165136     
FG Mikroelectronische Systeme         | FAX   : (49) 6151 164936    
Institut fur Datentechnik
Karl Strasse 15,
64283 Darmstadt
(GERMANY)
-----------------------------------------------------------------------
EMAIL : jose@microelectronic.e-technik.th-darmstadt.de
      : jca@inescn.pt (after July 17th, 1993)
-----------------------------------------------------------------------