This is the mail archive of the
mailing list for the GCC project.
Re: gcc port to StarCore
At 12:21 PM +0200 5/3/02, David Livshin wrote:
>Thank you very much for your help and assistance!
Just returning a fraction of the favors I've received from the other
readers of this list.
>Do you think that poor quality of the code for loops, generated by my port
>( that I reported earlier ), may be caused by the way I am ( currently )
>handling integer compare?
There's a very good chance of that. The UNSPEC confuses attempts to
"reason about" the
loop behavior, I'd guess.
>I hope I will be able to improve generated code based of your advice.
At 12:33 PM +0200 5/3/02, David Livshin wrote:
>I meant to ask if I have to use 'define_insn "cmpsi"' instead of
No. using named DEFINE_INSNs is just a shortcut for the common case
where the RTL expansion
done by the front-end (which uses the named patterns like "addsi3" or
"cmpsi") is the trivial
pattern provided in the DEFINE_xxx. In those cases, you don't need a
a DEFINE_INSN - the DEFINE_INSN provides both pieces of functionality
- the conversion from tree
to RTL and the conversion of RTL to assembly-language instructions.
> > The other thing that occurs to me is whether you've defined the
>> various COSTS macros (CONST_COSTS, ADDRESS_COST and RTX_COST). Also
>> check your LEGITIMATE_CONSTANT_P macro is reasonable....
>I will check it out and if wouldn't find any problems I will send you RTL
>dump as you requested.
I'm pretty sure that your biggest problem is using the UNSPECs..
You'll want to do those
other things, because it will help you generate better code (by
identifying WHEN it's better
to load a common sub-expression into a register, for example), but
those are second-order
kinds of improvements and the compiler typically does almost the
right thing by default.....
Quality Software Management
Software Process Improvement / Management Consulting
Language Design / Compiler Implementation