Jean Christophe Beyler writes:
> I set up your patch and I get an internal error on this test program:
You're right. I haven't handled the case properly when the constant itself
was an anchor constant (e.g. 0). Try this version.
Adam
* cse.c (get_const_anchors): New function.
If I replace your lines:
if ((GET_CODE (sets[i].src_elt->exp) == CONST_INT))
insert_const_anchors (dest, sets[i].src_elt, GET_MODE (dest));
with:
if ((GET_CODE (sets[i].src_elt->exp) == CONST_INT) && (INTVAL
(sets[i].src_elt->exp) != 0))
insert_const_anchors (dest, sets[i
I set up your patch and I get an internal error on this test program:
extern void foo(int, int);
extern int bar(void);
int startup;
void foobar()
{
int i;
while(1)
{
if (bar()) {
foo(0,0);
}
}
}
Here's the error:
/home/beyler/cyclops64/src/tnt/kernel/process_manager/testn
Adam Nemet writes:
> I am actually looking at something similar for PR33699 for MIPS. My plan is
> to experiment extending cse.c with putting "anchor" constants to the available
> expressions along with the original constant and then querying those later for
> constant expressions.
See http://gc
"Rahul Kharche" writes:
> GCSE won't help with your trimmed down example
>
> int main(void)
> {
> long a = 0xcafecafe;
>
> printf("Final: %lx %lx %lx\n", a, a+5, a+15);
> return EXIT_SUCCESS;
> }
>
> I believe Paolo's canon_reg solution together with tweaking
> rtx_cost of constants wi
> - If I patch in this code, actually I get the same results I did
> before where the constants are propagated. It seems that in 4.3.2,
> every part of the compiler is trying to do that.
There are at least two forward propagation passes, one before and
another after GCSE. I haven't tried to tackle
Hi Jean,
> Do you have a link to that patch? So that I can see if it applies for
me ?
See patch below. I put in some comments to try and explain what I have
attempted to do.
The hash SET generation, to track potential candidates in replacing a
register USE, needed some tweaking. This function wa
Dear all,
I was working on the machine description so I was postponing a bit
this problem but now I have a bit more time on my hands to handle it.
I'm starting to look at the various links and code you've provided me
and will keep you posted if I make any headway or not ;-).
> For the GCC port I
I am looking at a related problem in GCSE, GCC 4.3 whereby constants
are propagated to their use irrespective of the final instruction cost
of generating them (machine cycles or instruction count).
Global constant propagation effectively voids common expressions that
form large constants, identifi
Ian Lance Taylor:
that you are looking for. I'm not aware of any other processor which is
able to load a large constant in a single instruction, but for which an
add instruction is cheaper if there is a similar constant already
available.
Paul Brook:
This is true for Arm/Thumb. You have limite
On Friday 06 February 2009, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
> > All of these have an outer code of SET. Therefore, I'm not quite
> > positive of how I'm supposed to implement my rtx_cost function. Since
> > I don't seem to get a choice between a set 0xcb03 and a (plus 0xca
Jean Christophe Beyler wrote:
> Ok, thanks for all this information and if you can dig that up it
> would be nice too. I'll start looking at that patch and PR33699 to
> see if I can adapt them to my needs.
Here it is.
Paolo
/* Copy propagation on RTL for GNU compiler.
Copyright (C) 2006 Free
Ok, thanks for all this information and if you can dig that up it
would be nice too. I'll start looking at that patch and PR33699 to
see if I can adapt them to my needs. Any reason why you wouldn't
recommend it?
I will keep you posted of anything I do for latter reference,
Jean Christophe Beyler
Steven Bosscher wrote:
> On Fri, Feb 6, 2009 at 7:32 PM, Adam Nemet wrote:
>> I think you really need the Joern's optmize_related_values patch. Also see
>> PR33699.
>
> I wouldn't recommend that patch, but yes: Something that performs that
> optimization ;-)
Yes, something doing that using LCM
On Fri, Feb 6, 2009 at 7:32 PM, Adam Nemet wrote:
> I think you really need the Joern's optmize_related_values patch. Also see
> PR33699.
I wouldn't recommend that patch, but yes: Something that performs that
optimization ;-)
Gr.
Steven
Bernd Schmidt writes:
> Take a look at reload_cse_move2add.
I don't think that powerful enough; it requires the same destination
registers:
/* Try to transform (set (REGX) (CONST_INT A))
...
(set (REGX) (CONST_INT
Bernd Schmidt writes:
>> But I don't know that gcc will implement the particular optimization
>> that you are looking for. I'm not aware of any other processor which is
>> able to load a large constant in a single instruction, but for which an
>> add instruction is cheaper if there is a similar
Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> All of these have an outer code of SET. Therefore, I'm not quite
>> positive of how I'm supposed to implement my rtx_cost function. Since
>> I don't seem to get a choice between a set 0xcb03 and a (plus 0xcafe
>> 5), how can I tell the
Jean Christophe Beyler writes:
> All of these have an outer code of SET. Therefore, I'm not quite
> positive of how I'm supposed to implement my rtx_cost function. Since
> I don't seem to get a choice between a set 0xcb03 and a (plus 0xcafe
> 5), how can I tell the compiler the different costs?
On Fri, Feb 06, 2009 at 11:46:58AM -0500, Jean Christophe Beyler wrote:
> I finally get this :
>
> (const_int 51966 [0xcafe])
> (const_int 51966 [0xcafe])
> (const_int 51971 [0xcb03])
> (const_int 51971 [0xcb03])
>
> All of these have an outer code of SET. Therefore, I'm not quite
> positive of h
n. Since
I don't seem to get a choice between a set 0xcb03 and a (plus 0xcafe
5), how can I tell the compiler the different costs?
Jc
On Thu, Feb 5, 2009 at 4:10 PM, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> I'm currently working on removing the constant
Jean Christophe Beyler writes:
> I'm currently working on removing the constant folding and constant
> propagation because, on the architecture I'm working on, it is highly
> costly to move a constant into a register if the number is big (we can
> say over 16 bits).
&g
e Buck wrote:
> On Thu, Feb 05, 2009 at 12:46:01PM -0800, Joe Buck wrote:
>> On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
>> > I'm currently working on removing the constant folding and constant
>> > propagation because, on the archite
On Thu, Feb 05, 2009 at 12:46:01PM -0800, Joe Buck wrote:
> On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
> > I'm currently working on removing the constant folding and constant
> > propagation because, on the architecture I'm working on, it is hi
On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
> I'm currently working on removing the constant folding and constant
> propagation because, on the architecture I'm working on, it is highly
> costly to move a constant into a register if the number is big
Dear all,
I'm currently working on removing the constant folding and constant
propagation because, on the architecture I'm working on, it is highly
costly to move a constant into a register if the number is big (we can
say over 16 bits).
Currently, I've been looking into this and
26 matches
Mail list logo
