machine-dependent Passes on GIMPLE/SSA Tree's?

2006-11-27 Thread Markus Franke
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

poisened macro definitions

2006-12-05 Thread Markus Franke
PAREN" "ASM_GLOBALIZE_LABEL" "FUNCTION_ARG_PARTIAL_NREGS" --snap--- I read something about poisened macros and that they shouldn't be used anymore. But in fact I was not able to find any documentation about these macros. When were they declared as poisened and especially why? What should be done instead of using this macros? Just uncommenting everything can't be a solution. I was also looking in GCC-Internals manual without any success. Thanks for your help, Markus Franke

needed headerfiles in .c

2006-12-22 Thread Markus Franke
me 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

relevant files for target backends

2007-01-16 Thread Markus Franke
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

2007-01-16 Thread Markus Franke
Thank you for your response. I understood everything you said but I am still confused about the file -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 >>

Re: relevant files for target backends

2007-01-16 Thread Markus Franke
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 wher

order of local variables in stack frame

2007-01-23 Thread Markus Franke
rect 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

2007-01-23 Thread Markus Franke
(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 o

warning: source missing a mode?

2007-02-22 Thread Markus Franke
al\\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?

2007-02-22 Thread Markus Franke
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--- >>;; >&

Re: warning: source missing a mode?

2007-02-22 Thread Markus Franke
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 com

Re: warning: source missing a mode?

2007-02-22 Thread Markus Franke
uot;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

Re: warning: source missing a mode?

2007-02-26 Thread Markus Franke
e 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_retu

call_value pattern

2007-03-09 Thread Markus Franke
sage. ---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

error: unable to find a register to spill in class 'FP_REGS'

2007-03-14 Thread Markus Franke
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!

Re: error: unable to find a register to spill in class 'FP_REGS'

2007-03-15 Thread Markus Franke
ger 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

Re: error: unable to find a register to spill in class 'FP_REGS'

2007-03-16 Thread Markus Franke
. 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, aft