This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc port to StarCore



----- Original Message -----
From: Alan Lehotsky <apl@alum.mit.edu>
To: David Livshin <dlivshin@zahav.net.il>
Cc: Richard Henderson <rth@redhat.com>; <gcc@gcc.gnu.org>
Sent: Thursday, May 02, 2002 2:42 PM
Subject: Re: gcc port to StarCore


> At 3:16 PM +0200 5/2/02, David Livshin wrote:
> >.....
> >
> >Are you saying that in order to benefit from constant propagation in the:
> >
> >x = 10;
> >y = 100;
> >if ( x > y )
> >...
> >
> >'define_expand "cmpsi"' may not be used?
>
>
> Not to put words in Richard's mouth.....but.....
>
> What he's saying is that the DEFINE_EXPAND just produces the initial
> RTL, and as I mentioned earlier, the compiler will normally decide to
> load immediates to pseudos when it initially generates code.  You
> HAVE to use the "cmpsi" pattern otherwise, you'd never generate any
> compare RTL (although I think it may be the case that the compiler
> can generate calls to the runtime library to do compares out-of-line)
>

I meant to ask if I have to use 'define_insn "cmpsi"' instead of
'define_expand "cmpsi"'

>
> >Would you please direct me to a material ( source code and/or document )
> >that may clarify the way this optimization is implemented by the GNU
> >compiler. Right now I even cant guess what it might be. For example I
tried
> >in md:
> >
> >( define_insn "addsi3"
> >   [ ( set
> >       ( match_operand:SI 0 "register_operand"             "" )
> >       ( plus:SI ( match_operand:SI 1 "general_operand"   "" )
> >                 ( match_operand:SI 2 "general_operand" "" )
> >       )
> >     )
> >   ]
> >....
>
> Okay.  This pattern is missing all constraints.  (The characters
> inside the last "" on each match_operand)
> I'm not certain that would prevent constant folding (in fact I can't
> imagine how it could), but you should fix that before looking for
> other problems....
>
> 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.

Thank you,

David

>
>
> >and then compiled:
> >
> >x = 10;
> >y = 100;
> >z = x + y;
> >...
> >
> >It seems from the resulting code:
> >
> >  moveu.l #10,d0
> >  move.l d0,_x
> >  moveu.l #100,d2
> >  move.l d2,_y
> >  add #10,d2,d2
> >  move.l d2,_z
> >
> >that compiler understands that 'x' is equal to 10 but misses the fact
that
> >'y' is also a constant and 'z' is always equal to 110( or something
inside
> >the compiler forces the generation of the add instruction ). Just in-case
> >you are wondering: description of "movsi"  in my md file allows load of
any
> >constant to any register.
>
> An RTL dump would be a good thing to see, just to insure that the RTL
> you generated isn't munged in some unpredictable fashion.
>






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]