deutschlands einkaufsgemeinschaft nr.1 - iphone ohne vertrag für € 499,-

[snaaap.de]

>>> iphone 3g ohne vertrag für nur € 499,-   

>>> nintendo wii fit trainer set für nur € 199,-

>>> sony playstation III für nur € 299,-



"andere" haben die besten sprüche - wir haben die besten preise -> 
deutschlands einkaufsgemeinschaft #1 :

www.grandbuying.tv 




Dieser Newsetter ist kein SPAM. Sier erhalten ihn, weil Sie bei Ihrer 
Anmeldung bei uns bzw. auf unseren Partnerseiten dem Newsletterempfang 
zugestimmt haben. Eine Austragung ist selbstverständlich moeglich indem Sie 
uns auf diese Email mit dem Inhalt "STOPP NEWSLETTER" antworten.

deutschlands einkaufsgemeinschaft nr.1 - iphone ohne vertrag für € 499,-

[snaaap.de]

>>> iphone 3g ohne vertrag für nur € 499,-   

>>> nintendo wii fit trainer set für nur € 199,-

>>> sony playstation III für nur € 299,-



"andere" haben die besten sprüche - wir haben die besten preise -> 
deutschlands einkaufsgemeinschaft #1 :

www.grandbuying.tv 




Dieser Newsetter ist kein SPAM. Sier erhalten ihn, weil Sie bei Ihrer 
Anmeldung bei uns bzw. auf unseren Partnerseiten dem Newsletterempfang 
zugestimmt haben. Eine Austragung ist selbstverständlich moeglich indem Sie 
uns auf diese Email mit dem Inhalt "STOPP NEWSLETTER" antworten.

IRA copy heuristics

[Richard Sandiford]

As I mentioned in:

http://gcc.gnu.org/ml/gcc/2008-08/msg00476.html

I'd been working on a MIPS IRA port, but got side-tracked by a wrong-code
regression.

The regression was caused by incorrect EH liveness information. I tried
to "fix" it by replacing the current note_stores-based forward scan with
a DF-based backwards scan, which gave us the corrected information for free.
However, even after Vlad fixed a pessimisation wrt calls and
DF_REF_MAY_CLOBBER, he saw a significant decrease in SPECFP performance.
It seemed to me (and I think to Vlad) that the differences were caused
by the "inverted" ALLOCNO_NUM ordering.  Before the patch, allocno
indexes typically increased as you went from the beginning of a region
to the end, whereas it was the other way around after the patch.

In other words, a lot of the difference seemed to be down to the
last line of bucket_allocno_compare_func:

static int
bucket_allocno_compare_func (const void *v1p, const void *v2p)
{
  ira_allocno_t a1 = *(const ira_allocno_t *) v1p;
  ira_allocno_t a2 = *(const ira_allocno_t *) v2p;
  int diff, a1_freq, a2_freq, a1_num, a2_num;

  if ((diff = (int) ALLOCNO_COVER_CLASS (a2) - ALLOCNO_COVER_CLASS (a1)) != 0)
return diff;
  get_coalesced_allocnos_attributes (a1, &a1_freq, &a1_num);
  get_coalesced_allocnos_attributes (a2, &a2_freq, &a2_num);
  if ((diff = a2_num - a1_num) != 0)
return diff;
  else if ((diff = a1_freq - a2_freq) != 0)
return diff;
  return ALLOCNO_NUM (a2) - ALLOCNO_NUM (a1);
}

This line is really just a tie-breaker, but changing:

  return ALLOCNO_NUM (a2) - ALLOCNO_NUM (a1);

to:

  return ALLOCNO_NUM (a1) - ALLOCNO_NUM (a2);

has a significant effect on the results.  The question then
(and now) is: is that Just One Of Those Things?  I realise we're
dealing with an NP problem, and that we can't expect perfect results.
So is the influence of the allocno index ordering acceptable?

I wasn't sure either way, and found a simple case where, with the
reversed order, the copy costs were actually causing us to pick
the one register that would induce a copy reload.  Unfortunately,
that particular testcase no longer exhibits the problem, so I redid
the experiment on trunk and picked an arbitrary example of where
the reversed order was causing a difference.  (In this case,
the reversed order is better, because it avoids a copy.)

It turned out not to be quite the same problem that I'd seen before,
but the underlying questions about the copy costs are the same.
It also shows a potential problem with operand ties involving
hard registers.

I've attached a patch that replaces ALLOCNO_NUM comparisons with
a new macro, ALLOCNO_COMPARE.  Apply the patch as-is to swap the order.
Replace:

#define ALLOCNO_COMPARE(A1, A2) (ALLOCNO_NUM (A2) - ALLOCNO_NUM (A1))

with:

#define ALLOCNO_COMPARE(A1, A2) (ALLOCNO_NUM (A1) - ALLOCNO_NUM (A2))

to keep the current order.

I've also attached the DF patch, although you don't need it for what follows.

The testcase I picked was gcc/testsuite/gcc.dg/tree-ssa/reassoc-13.c,
compiled at -Os on x86_64-linux-gnu.  The rtl for the function is:

(insn:HI 6 3 7 2 ../../../../new/gcc/testsuite/gcc.dg/tree-ssa/reassoc-13.c:7 
(set (reg:DF 61)
(mem/u/c/i:DF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [2 S8 A64])) 103 
{*movdf_integer_rex64} (expr_list:REG_EQUAL (const_double:DF 5.0e+0 [0x0.ap+3])
(nil)))

(insn:HI 7 6 8 2 ../../../../new/gcc/testsuite/gcc.dg/tree-ssa/reassoc-13.c:7 
(set (reg/v:DF 58 [ tmp2 ])
(plus:DF (reg/v:DF 60 [ a ])
(reg:DF 61))) 734 {*fop_df_comm_sse} (nil))

(insn:HI 8 7 9 2 ../../../../new/gcc/testsuite/gcc.dg/tree-ssa/reassoc-13.c:7 
(set (reg:DF 63)
(minus:DF (reg/v:DF 58 [ tmp2 ])
(reg/v:DF 60 [ a ]))) 745 {*fop_df_1_sse} (expr_list:REG_DEAD 
(reg/v:DF 58 [ tmp2 ])
(nil)))

(insn:HI 9 8 11 2 ../../../../new/gcc/testsuite/gcc.dg/tree-ssa/reassoc-13.c:7 
(set (reg:DF 64)
(plus:DF (reg/v:DF 60 [ a ])
(reg:DF 63))) 734 {*fop_df_comm_sse} (expr_list:REG_DEAD (reg:DF 63)
(expr_list:REG_DEAD (reg/v:DF 60 [ a ])
(nil

(insn:HI 16 11 22 2 
../../../../new/gcc/testsuite/gcc.dg/tree-ssa/reassoc-13.c:10 (set (reg/i:DF 21 
xmm0)
(minus:DF (reg:DF 64)
(reg:DF 61))) 745 {*fop_df_1_sse} (expr_list:REG_DEAD (reg:DF 64)
(expr_list:REG_DEAD (reg:DF 61)
(nil

So let's use "Rx" to refer to pseudo register X, "Ax" to refer to
its allocno, and "Hx" to refer to its allocated hard register.
Allocnos are popped and allocated in the following orders:

Original  Reversed
  
A60   A60
A61   A61
A58   A64
A63   A63
A64   A58

Both orders agree on the following assignments:

H58 = xmm2
H60 = xmm0
H61 = xmm1
H63 = xmm2

The problem is with the allocation of A64.  R64 is tied twice:

- to R60 or R63 in insn 9
- to xmm0 in insn 16

Both orderings set H60 to x

Re: insn does not satisfy its constraints

[Mohamed Shafi]

- Original Message 
> From: Omar Torres <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: gcc@gcc.gnu.org
> Sent: Saturday, August 30, 2008 12:11:36 AM
> Subject: Re: insn does not satisfy its constraints
> 
> shafi wrote:
> >Operand 0 is a register
> >Operand 1 is a memory
> >Operand 2 is a register
> >
> >
> >> The md description for this instruction is:
> >>
> >> ;; addhi3
> >> (define_expand "addhi3"
> >>   [(set (match_operand:HI 0 "register_operand" "")
> >> (plus:HI (match_operand:HI 1 "cool_addhi_operand"  "")
> >>  (match_operand:HI 2 "cool_addhi_operand"  "")))]
> >>   ""
> >>   "")
> >>
> >> (define_insn "*addhi3"
> >>   [(set (match_operand:HI 0 "register_operand""=r ,r  ,r")
> >> (plus:HI (match_operand:HI 1 "cool_addhi_operand" "%0 ,rim,r")
> >>  (match_operand:HI 2 "cool_addhi_operand" "rim,0  ,r")))]
> >>   ""
> >>
> >
> >Do you have an option where operand 0 is reg and operand 1 is mem and
> > operand 2 is reg?
> >
> My purpose is to describe the three possible scenarios:
> 1)  Operand 0 is a register
>  Operand 1 is the same register as operand 0
>  Operand 2 is a register, immediate or memory
> 
> 2)  Operand 0 is a register
>  Operand 1 is a register, immediate or memory
>   Operand 2 is the same register as operand 0
> 
> 3)  Operand 0 is a register
>  Operand 2 is a register
>  Operand 3 is also a register
> 
> 
> >I am not sure what rim is for?
> >
> rim = is a short cut for r, m, i. I think is is allow to mix several
> constrains like this, right?
> 
   So rim is a user define constraint. Then i think you may want to look 
properly into EXTRA_CONSTRAINT_STR. Probably this is where you might be going 
wrong.

HTH
Shafi



  

Re: new file for testsuite gcc.dj

[Niklaus]

On 8/26/08, Janis Johnson <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-08-24 at 16:41 +0530, Niklaus wrote:
>  > i ran with this file under testsuite/gcc.dj and it aborted with -O2.
>  > It is for the optimization bug that i reported few days back. If we
>  > don't have this test can someone add ths.
>
>
> File a bug report, if you haven't already, and include the test case
>  in the bug report.  When the bug is fixed the patch will include a
>  new test, which will either be the one you provided or something
>  based on it.
>

Andrew pinksi said this bug wasn't occuring in the latest trunk. So
should i open a bug against gcc 4.2 and include this ? i posted this
so that we don't have regression.