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
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
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
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
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
>>
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
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
(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
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
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---
>>;;
>&
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
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
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
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
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!
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
. 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
17 matches
Mail list logo