Re: error: unable to find a register to spill in class 'FP_REGS'
Again with attachment and CC to the Mailing List. Sorry for missing this.
Regards,
Markus
---
Hello,
thanks for your instructions. Indeed you were right. I mixed up some files.
Again an excerpt of the output-files:
---snip--- // expand
(insn 45 47 46 1 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4)
(reg:SI 93 [ D.1211 ])) -1 (nil)
(expr_list:REG_NO_CONFLICT (reg:SI 93 [ D.1211 ])
(nil)))
---snap---
---snip--- // lreg
(insn 45 47 46 0 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4)
(reg:SI 93 [ D.1211 ])) 40 {movsi_general} (nil)
(expr_list:REG_DEAD (reg:SI 93 [ D.1211 ])
(expr_list:REG_NO_CONFLICT (reg:SI 93 [ D.1211 ])
(nil
---snap---
---snip--- // greg
;; Function main (main)
Spilling for insn 45.
---snap---
Aditionally, you can find the three files in the attachment. It would be
really nice of you if you could have a look at it. Maybe you can get a
clue what's going wrong.
Regards,
Markus Franke
Jim Wilson wrote:
Markus Franke wrote:
That means the compiler has to reload the pseudo registers 92 and 93 for
this instruction, right?
First we do register allocation. Then, after register allocation, if
the chosen hard registers don't match the constraints, then we use
reload to fix it.
The relevant data for instruction 45 in .greg looks like that:
Insn 45 in the greg dump looks nothing like the insn 45 in the expand
dump, which means you are looking at the wrong insn here. But it was
insn 45 in the original mail. Did you change the testcase perhaps? Or
use different optimization options?
The info we are looking for should look something like this
Reloads for insn # 13
Reload 0: reload_out (SI) = (reg:SI 97)
R1_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg:SI 97)
reload_reg_rtx: (reg:SI 1 %r1)
;; Register 92 in 9.
;; Register 93 in 10.
This tells us that pseudo 92 was allocated to hard reg 9, and pseudo 93
was allocated to hard reg 10. I didn't see reg class preferencing info
for these regs, but maybe it is in one of the other dump files.
The earlier message has rtl claiming that pseudo 92 got allocated to
register 1 (r1). I seem to be getting inconsistent information here.
--
Nichts ist so praktisch wie eine gute Theorie!
;; Function main (main)
;; Generating RTL for tree basic block 0
;;
;; Full RTL generated for this function:
;;
(note 2 0 6 NOTE_INSN_DELETED)
;; Start of basic block 0, registers live: (nil)
(note 6 2 3 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(note 3 6 180 0 NOTE_INSN_FUNCTION_BEG)
(insn 180 3 4 0 (set (reg:SI 139)
(reg/f:SI 29 r29)) -1 (nil)
(nil))
(note 4 180 5 0 NOTE_INSN_DELETED)
(call_insn 5 4 7 0 (parallel [
(call (mem:QI (symbol_ref:SI (__main) [flags 0x41]) [0 S1 A8])
(const_int 0 [0x0]))
(clobber (reg:SI 31 r31))
]) -1 (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
;; End of basic block 0, registers live:
(nil)
;; Start of basic block 1, registers live: (nil)
(note 7 5 8 1 [bb 1] NOTE_INSN_BASIC_BLOCK)
(insn 8 7 9 1 (set (reg:SI 108)
(reg/f:SI 29 r29)) -1 (nil)
(nil))
(insn 9 8 11 1 (set (reg:SI 70 [ saved_stack3 ])
(reg:SI 108)) -1 (nil)
(nil))
(insn 11 9 12 1 (set (reg/f:SI 109)
(symbol_ref:SI (c) [flags 0x2] var_decl 0x3adb3108 c)) -1 (nil)
(nil))
(insn 12 11 13 1 (set (reg:HI 106 [ c0 ])
(mem/c/i:HI (reg/f:SI 109) [0 c+0 S2 A16])) -1 (nil)
(nil))
(insn 13 12 14 1 (set (reg:SI 105 [ D.1199 ])
(sign_extend:SI (reg:HI 106 [ c0 ]))) -1 (nil)
(nil))
(insn 14 13 15 1 (set (reg:SI 104 [ D.1200 ])
(plus:SI (reg:SI 105 [ D.1199 ])
(const_int -1 [0x]))) -1 (nil)
(nil))
(insn 15 14 16 1 (set (reg:SI 103 [ D.1201 ])
(reg:SI 104 [ D.1200 ])) -1 (nil)
(nil))
(insn 16 15 19 1 (set (reg:SI 102 [ D.1202 ])
(sign_extend:SI (reg:HI 106 [ c0 ]))) -1 (nil)
(nil))
(insn 19 16 17 1 (clobber (reg:DI 101 [ D.1203 ])) -1 (nil)
(insn_list:REG_LIBCALL 18 (nil)))
(insn 17 19 18 1 (set (subreg:SI (reg:DI 101 [ D.1203 ]) 4)
(reg:SI 102 [ D.1202 ])) -1 (nil)
(expr_list:REG_NO_CONFLICT (reg:SI 102 [ D.1202 ])
(nil)))
(insn 18 17 22 1 (set (subreg:SI (reg:DI 101 [ D.1203 ]) 0)
(const_int 0 [0x0])) -1 (nil)
(insn_list:REG_RETVAL 19 (expr_list:REG_NO_CONFLICT (reg:SI 102 [ D.1202 ])
(nil
(insn 22 18 20 1 (clobber (reg:DI 110)) -1 (nil)
(insn_list:REG_LIBCALL 21 (nil)))
(insn 20 22 21 1 (set (subreg:SI (reg:DI 110) 0)
(and:SI (subreg:SI (reg:DI 101 [ D.1203 ]) 0)
(const_int 15 [0xf]))) -1 (nil)
(expr_list:REG_NO_CONFLICT (reg:DI 101 [ D.1203 ])
(nil)))
(insn 21 20 25 1 (set (subreg:SI (reg:DI 110) 4)
(and:SI (subreg:SI (reg:DI 101 [ D.1203 ]) 4)
(const_int -1 [0x]))) -1 (nil)
(insn_list:REG_RETVAL 22 (expr_list:REG_NO_CONFLICT (reg:DI 101
Re: error: unable to find a register to spill in class 'FP_REGS'
Hello, thanks for your answer. Here is an excerpt of the .00.expand file for insn 45: ---snip--- (insn 45 47 46 1 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4) (reg:SI 93 [ D.1211 ])) -1 (nil) (expr_list:REG_NO_CONFLICT (reg:SI 93 [ D.1211 ]) (nil))) ---snap--- That means the compiler has to reload the pseudo registers 92 and 93 for this instruction, right? Jim Wilson wrote: and lreg ones. The greg one will have a section listing all of the reloads generated, find the list of reloads generated for this insn 45. The relevant data for instruction 45 in .greg looks like that: ---snip--- ;; Function main ;; Need 2 regs of class FP_REGS (for insn 15). ;; Need 2 regs of class ALL_REGS (for insn 15). Spilling reg 32. Spilling reg 33. ;; Register dispositions: 69 in 3 70 in 8 71 in 4 72 in 8 73 in 5 74 in 8 75 in 6 76 in 1 77 in 8 78 in 9 79 in 10 80 in 9 81 in 8 82 in 9 83 in 8 84 in 10 85 in 8 86 in 9 87 in 8 88 in 8 89 in 9 90 in 7 91 in 9 92 in 9 93 in 10 94 in 2 ;; Hard regs used: 1 2 3 4 5 6 7 8 9 10 29 30 31 32 33 SOME OTHER INSTRUCTIONS (insn 45 44 47 (use (reg:SI 8 r8)) -1 (nil) (nil)) SOME OTHER INSTRUCTIONS ---snap--- lreg will have info about register class preferencing. It will tell you what register class the compiler wants to use for this insn. Same for the .lreg file: ---snip--- ;; Function main 95 registers. Register 69 used 7 times across 0 insns. Register 70 used 2 times across 0 insns; pointer. Register 71 used 6 times across 0 insns. Register 72 used 2 times across 0 insns. Register 73 used 6 times across 0 insns. Register 74 used 2 times across 0 insns; pointer. Register 75 used 7 times across 0 insns. Register 76 used 2 times across 0 insns; pref FP_REGS. Register 77 used 4 times across 0 insns. Register 78 used 2 times across 0 insns. Register 79 used 2 times across 0 insns. Register 80 used 2 times across 0 insns. Register 81 used 2 times across 0 insns. Register 82 used 2 times across 0 insns. Register 83 used 2 times across 0 insns. Register 84 used 2 times across 0 insns. Register 85 used 2 times across 0 insns; pref FP_REGS; pointer. Register 86 used 2 times across 0 insns. Register 87 used 2 times across 0 insns. Register 88 used 4 times across 0 insns. Register 89 used 2 times across 0 insns. Register 90 used 6 times across 0 insns. Register 91 used 2 times across 0 insns. Register 92 used 2 times across 0 insns; pointer. Register 93 used 2 times across 0 insns. Register 94 used 2 times across 0 insns; crosses 1 call; pref FP_REGS. 0 basic blocks. ;; Register 69 in 3. ;; Register 70 in 8. ;; Register 71 in 4. ;; Register 72 in 8. ;; Register 73 in 5. ;; Register 74 in 8. ;; Register 75 in 6. ;; Register 76 in 1. ;; Register 77 in 8. ;; Register 78 in 9. ;; Register 79 in 10. ;; Register 80 in 9. ;; Register 81 in 8. ;; Register 82 in 9. ;; Register 83 in 8. ;; Register 84 in 10. ;; Register 85 in 8. ;; Register 86 in 9. ;; Register 87 in 8. ;; Register 88 in 8. ;; Register 89 in 9. ;; Register 90 in 7. ;; Register 91 in 9. ;; Register 92 in 9. ;; Register 93 in 10. ;; Register 94 in 2. SOME OTHER INSTRUCTIONS (insn 45 44 47 (use (reg:SI 88)) -1 (nil) (nil)) SOME OTHER INSTRUCTIONS ---snap--- The fact that this insn doesn't do FP isn't important. What is important is how the pseudo-regs are used. If the pseudo-reg 92 is used in 10 insns, and 8 of them are FP insns and 2 are integer move insns, then the register allocator will prefer an FP reg, since that should give the best overall result, as only 2 insns will need reloads. If it used an integer reg, then 8 insns would need reloads. Ok that's clear. Thanks for explaining. Nevertheless I can't figure out from the above files what's wrong and maybe I am just lacking of the right interpretation of these intermediate files. Can you figure out any abnormal behaviour from the above file excerpts? Thanks in advance, Markus Franke
error: unable to find a register to spill in class 'FP_REGS'
Dear GCC Developers/Users,
I am working on a port of a target backend. I have a problem when
compiling the following program:
---snip---
short b = 5;
short c = 5;
int main(void)
{
long int a[b][c];
a[1][1]=5;
return 0;
}
---snap---
During compilation I get the following error message:
---snip---
simple_alloc.c: In function 'main':
simple_alloc.c:8: error: unable to find a register to spill in class
'FP_REGS'
simple_alloc.c:8: error: this is the insn:
(insn 45 47 46 0 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4)
(reg:SI 1 r1 [orig:93 D.1211 ] [93])) 40 {movsi_general} (nil)
(expr_list:REG_DEAD (reg:SI 1 r1 [orig:93 D.1211 ] [93])
(expr_list:REG_NO_CONFLICT (reg:SI 1 r1 [orig:93 D.1211 ] [93])
(nil
simple_alloc.c:8: confused by earlier errors, bailing out
---snap---
After a while of diving through gcc source code I can't get a clue
what's going wrong.
The problem is that the reloading stage fails because it can't find any
free registers for spilling, right? But the compiler says that it wants
to spill in class 'FP_REGS' and the above RTL-statement doesn't have
anything to do with floating point arithmetic!?!?!
I found out that in gcc/reload1.c:find_reg() the following
if-statement never gets satisfied:
---snip---
if (! TEST_HARD_REG_BIT (not_usable, regno)
! TEST_HARD_REG_BIT (used_by_other_reload, regno)
HARD_REGNO_MODE_OK (regno, rl-mode))
---snap---
This causes in the end the error message because no suitable registers
could be found.
Does anybody have an idea what could be wrong in the machine description
or to where start finding the error?
Any suggestions are welcome.
Regards,
Markus Franke
--
Nichts ist so praktisch wie eine gute Theorie!
call_value pattern
Dear GCC Developers,
I have a rather simple piece of a call_value instruction pattern in my
machine description:
---snip---
(define_insn call_value
[(set (match_operand 0 )
(call (match_operand:QI 1 )
(match_operand:SI 2 )))]
jal\\t%S0%(
[(set_attr type jump)
(set_attr mode none)])
---snap---
However when I try to compile the following example I get a Internal
Compiler Error message.
---snip---
int odd(int i)
{
return i 0x1;
}
int foo(int i, int j)
{
int a;
a=odd(i+j);
return a;
}
---snap---
If simply omit the a=odd(i+j)-line everything works fine so it has
something to do with this call.
What am I doing wrong? It seems so simple but I can't figure out what's
wrong with my pattern.
Regards,
Markus Franke
Re: warning: source missing a mode?
Hello,
thanks for reply. I was reading and comparing machine description files
from other backends. Now I am using a template like this:
---snip---
(define_insn call_value
[(parallel [(set (match_operand 0 )
(call (mem:QI (match_operand:QI 1 sym_ref_mem_operand
))
(match_operand:SI 2 )))
(clobber (reg:SI 31))])]
jal\\t%S0%(
[(set_attr type jump)
(set_attr mode none)])
---snap---
This pattern matches for function calls but unfortunately now I get a
segmentation fault during compilation of the following program:
---snip---
int odd(int i)
{
return i 0x1;
}
int
foo(int i, int j)
{
int a;
a=odd(i+j);
return a;
}
---snap---
The segmentation fault occurs in the last line of the foo()-function.
Any suggestions?
Regards and thanks for any comments,
Markus
Richard Henderson wrote:
On Thu, Feb 22, 2007 at 11:10:09AM +0100, Markus Franke wrote:
;; calls that return int in r1
;;
(define_insn call_val_internal_return_r1
[(parallel [(set (reg:SI 1)
(call (match_operand:QI 0 sym_ref_mem_operand )
Why would you have a specific pattern for (reg:SI 1) as
the return value? I suggest you look at other ports for
guidence here. Normal is something like
(define_insn *call_value_1
[(set (match_operand 0 )
(call (mem:QI (match_operand:SI 1 call_insn_operand rsm))
(match_operand:SI 2 )))]
...)
where both the return value and the call have no mode specified.
r~
--
Nichts ist so praktisch wie eine gute Theorie!
warning: source missing a mode?
Dear GCC Developers, I have problems with a dlx backend, which I have ported to GCC 4.1.1. During compilation of gcc I get warnings about missing mode definitions in the machine description file. The following instruction template is affected: ---snip--- ;; ;; calls that return int in r1 ;; (define_insn call_val_internal_return_r1 [(parallel [(set (reg:SI 1) (call (match_operand:QI 0 sym_ref_mem_operand ) (match_operand 1 i))) (clobber (reg:SI 31))])] jal\\t%S0%( [(set_attr type jump) (set_attr mode none)]) ---snap--- I think the warning is caused by the second parameter of the set instruction, right? But I don't know where to specify the source mode. I had already a look into the GCC Internals Manual without success. Any suggestions how to fix this problem? Regards, Markus Franke
Re: warning: source missing a mode?
Hello, thank you for your answer. Having changed the code in the way you suggested I get still the same warning message. Any further suggestions? Regards, Markus Ian Lance Taylor wrote: Markus Franke [EMAIL PROTECTED] writes: ---snip--- ;; ;; calls that return int in r1 ;; (define_insn call_val_internal_return_r1 [(parallel [(set (reg:SI 1) (call (match_operand:QI 0 sym_ref_mem_operand ) (match_operand 1 i))) (clobber (reg:SI 31))])] jal\\t%S0%( [(set_attr type jump) (set_attr mode none)]) ---snap--- I think the warning is caused by the second parameter of the set instruction, right? But I don't know where to specify the source mode. I had already a look into the GCC Internals Manual without success. The missing mode is here: (match_operand 1 i) That should most likely be (match_operand:SI 1 i) Ian -- Nichts ist so praktisch wie eine gute Theorie!
Re: warning: source missing a mode?
Ian Lance Taylor wrote: Oh, yeah, you probably want to say call:SI too. Yes I can do this and the warning message disappears. But now I get an internal error message about a non matching rtl expression when compiling a test program. Without call:SI I get warnings during compilation but the compilation of my test program works. :-)
Re: warning: source missing a mode?
Ian Lance Taylor wrote: Presumably the insn which doesn't match uses call with some mode other than SI. What mode does it use? What generated that insn with some other mode? Well, the internal compiler error message which is thrown looks like this: ---snip--- Processing file 2120-2.c 2120-2.c: In function 'foo': 2120-2.c:13: error: unrecognizable insn: (call_insn 14 13 15 1 (parallel [ (set:SI (reg:SI 1 r1) (call (mem:QI (symbol_ref:SI (odd) [flags 0x3] function_decl 0x3ae24700 odd) [0 S1 A8]) (const_int 8 [0x8]))) (clobber (reg:SI 31 r31)) ]) -1 (nil) (expr_list:REG_EH_REGION (const_int 0 [0x0]) (nil)) (nil)) 2120-2.c:13: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. ---snap--- By the way, this source code file is from the GCC testsuite. (torture tests) My corresponding rtl template looks now like following one: ---snip--- ;; ;; calls that return int in r1 ;; (define_insn call_val_internal_return_r1 [(parallel [(set (reg:SI 1) (call:SI (match_operand:QI 0 sym_ref_mem_operand ) (match_operand:SI 1 i))) (clobber (reg:SI 31))])] jal\\t%S0%( [(set_attr type jump) (set_attr mode none)]) ---snap--- Actually, most targets don't use a mode with call, since a call can often return multiple modes. But then they don't use a mode for the result of the call, either. Look at what other targets do. Till, now I haven't found a similar template where the return value which is set is a reg:SI. I will keep on searching :-) Regards, Markus Franke
order of local variables in stack frame
Dear GCC Developers,
I am working on a target backend for the DLX architecture and I have a
question concerning the layout of the stack frame.
Here is a simple test C-program:
---snip---
int main(void)
{
int a = 1;
int b = 2;
int c = a + b;
return c;
}
---snap---
The initialisation of the variables a and b produce the following output:
---snip---
movl$1, -24(%ebp)
movl$2, -20(%ebp)
---snap---
Although I have declared STACK_GROWS_DOWNWARD the variables a and b
are lying upwards in memory (-24 -20). Shouldn't it be the other way
around because the stack should grow downwards towards smaller
addresses. I think it should be like this:
---snip---
movl$1, -20(%ebp)
movl$2, -24(%ebp)
---snap---
Please let me know whether I missunderstood something completely. If
this behaviour is correct what can I do to change it to the other way
around. Which macro variable do I have to change?
Thanks in advance,
Markus Franke
Re: order of local variables in stack frame
Well, you are right. The code looks good and works also. But I have some kind of a reference implementation which is based on GCC 2.7.2.3. In this version the local variables are allocated the other way around, the way in which I expected. Obviously, the order of allocation has changed till now (4.1.1). I just wanted to know whether I can correct this, but if not its also OK. Thanks, Markus Robert Dewar wrote: Markus Franke wrote: Please let me know whether I missunderstood something completely. If this behaviour is correct what can I do to change it to the other way around. Which macro variable do I have to change? There is no legitimate reason to care about the order of variables in the local stack frame! Or at least I don't see one, why do *you* care? Generally one may want to reorder the variables for alignment purposes anyway. -- Nichts ist so praktisch wie eine gute Theorie!
relevant files for target backends
Dear GCC Developers/Users, I am trying to port a backend from GCC version 2.7.2.3 to version 4.1.1. As far as I have seen, a lot of new relevant files were introduced to build a good structure for new backends. I am wondering where to define the prototypes for functions in machine.c Shall the prototypes be defined in machine-protos.h or in machine.h or in machine.c. As far as I understand the prototypes should be defined in machine-protos.h, right? But if I do so several errors/warnings arise because of undeclared prototypes. Another question is where target macros should be defined. As far as I can see machine.c has something like such a structure: ---snip--- #define SOME_MACRO #define SOME_MACRO #define SOME_MACRO #define SOME_MACRO struct gcc_target targetm = TARGET_INITIALIZER; ---snap--- But there are also a lot of macros defined in machine.h. What kind of macros should be defined in machine.h and which macros should be defined in machine.c? I try to write good and standardised code in order to contribute my development. I would appreciate any help. By the way, I already had a look in the GCC Internals manual but I am still a bit confused. Thanks in advance and regards, Markus Franke
Re: relevant files for target backends
Thank you for your response. I understood everything you said but I am still confused about the file machine-protos.h. Which prototypes have to be defined there? Thanks in advance, Markus Franke pranav bhandarkar wrote: I am wondering where to define the prototypes for functions in machine.c Shall the prototypes be defined in machine-protos.h or in machine.h or in machine.c. As far as I understand the prototypes should be defined in machine-protos.h, right? But if I do so several errors/warnings arise because of undeclared prototypes. Another question is where target macros should be defined. As far as I can see machine.c has something like such a structure: ---snip--- #define SOME_MACRO #define SOME_MACRO #define SOME_MACRO #define SOME_MACRO struct gcc_target targetm = TARGET_INITIALIZER; machine.h is used to define macros that give such information as the register classes, whether little endian or not, sizes of integral types etc. The file machine.c, like you rightly said defines the targetm structure that holds pointers to target related functions and data. Such functions are defined in the .c file. Such target hooks are #defined in the .c file. HTH, Pranav -- Nichts ist so praktisch wie eine gute Theorie!
Re: relevant files for target backends
Thank you very much. That was exactly the information I was looking for. I will think about a contribution to the GCC Internals. Thanks again, Markus Franke Rask Ingemann Lambertsen wrote: On Tue, Jan 16, 2007 at 11:24:56AM +0100, Markus Franke wrote: I am wondering where to define the prototypes for functions in machine.c Shall the prototypes be defined in machine-protos.h or in machine.h or in machine.c. As far as I understand the prototypes should be defined in machine-protos.h, right? But if I do so several errors/warnings arise because of undeclared prototypes. All functions and variables not declared static in machine.c should have a prototype in machine-protos.h. Also, does this patch help? Index: gcc/var-tracking.c === --- gcc/var-tracking.c(revision 120287) +++ gcc/var-tracking.c(working copy) @@ -106,6 +106,7 @@ #include expr.h #include timevar.h #include tree-pass.h +#include tm_p.h /* Type of micro operation. */ enum micro_operation_type But there are also a lot of macros defined in machine.h. What kind of macros should be defined in machine.h and which macros should be defined in machine.c? Those listed as macros in the documentation should go into machine.h while those listed as target hooks should go into machine.c. I try to write good and standardised code in order to contribute my development. I would appreciate any help. By the way, I already had a look in the GCC Internals manual but I am still a bit confused. I would like to encurage you to submit a patch for the GCC Internals manual to make it clearer. -- Nichts ist so praktisch wie eine gute Theorie!
needed headerfiles in machine.c
Dear GCC Developers / Users, I am trying to port a GCC-Backend from GCC 2.7.2.3 to GCC 4.1.1. After having had a look on some already existing backends like the PDP11, I found out that there have been a lot of new Header-Files added to machine.c as includes. My question is now whether some kind of standard set of Header-Files exists which is needed by every backend? Can somebody give me a list or something like that. I had already a look at the Internals Manual but without finding something about it. Thanks in advance, Markus Franke
machine-dependent Passes on GIMPLE/SSA Tree's?
Dear GCC Developers, I am currently trying to get familiar with basic functionalities (and their implementation) of the GCC (cc1). After generating the GIMPLE representation of the Input-Parse-Tree a huge number of optimisation passes takes place. These passes are said to be hardware independent. However I am wondering, whether there are maybe also some passes which make use of machine descriptions. I am thinking about some Loop-Optimisations which can be performed much better if the appropriate optimisation pass knows if there are vector machine instructions. This would allow to parallelize the loop. (Tree level if-conversion for vectorizer) Are there also some other optimisation passes working on the GIMPLE/SSA representation which make use of any machine-dependent features? Thanks for help, Markus Franke
