мой зайчик.))

[Руся Эрнет]

привет зай..!))) 
если скучно и хош зазнакомиться ПoлинaБeлoвa_ndivhfj.land.ru имя моё там. 

Re: A question about loop ivopt

[Richard Guenther]

On Tue, May 15, 2012 at 7:05 AM, Jiangning Liu  wrote:
> Hi,
>
> Why can't we replace function force_expr_to_var_cost directly with function
> computation_cost in tree-ssa-loop-ivopt.c?
>
> Actually I think it is inaccurate for the current recursive algorithm in
> force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
> count some back-end factors and make the estimation more accurate.
>
> For example, using computation_cost, we may check whether back-ends can tie
> some modes transformation expressed by SUBREG or not. If we use
> force_expr_to_var_cost, some more computations around type
> promotion/demotion would increase the cost estimated.
>
> Looking at the algorithm in force_expr_to_var_cost, it is just to analyze
> the operator in the expression and give estimation. Should it be the same as
> expanding EXPR to RTX and give estimation like in computation_cost?
>
> Any thoughts?

I suppose Zdenek may remember.

Richard.

> Thanks,
> -Jiangning
>
>
>

Re: A question about loop ivopt

[Zdenek Dvorak]

Hi,

> > Why can't we replace function force_expr_to_var_cost directly with function
> > computation_cost in tree-ssa-loop-ivopt.c?
> >
> > Actually I think it is inaccurate for the current recursive algorithm in
> > force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
> > count some back-end factors and make the estimation more accurate.
> >
> > For example, using computation_cost, we may check whether back-ends can tie
> > some modes transformation expressed by SUBREG or not. If we use
> > force_expr_to_var_cost, some more computations around type
> > promotion/demotion would increase the cost estimated.
> >
> > Looking at the algorithm in force_expr_to_var_cost, it is just to analyze
> > the operator in the expression and give estimation. Should it be the same as
> > expanding EXPR to RTX and give estimation like in computation_cost?
> >
> > Any thoughts?
> 
> I suppose Zdenek may remember.

computation_cost actually expands the expression to RTL.  Since cost estimates
are computed a lot in ivopts, using it directly would require a huge amount of 
memory,

Zdenek

Help with 'ev_sl' PowerPC SPE Intrinsic

[Rohit Arul Raj]

Hello All,

I need some help regarding implementation of one of the SPE instructions.

I am planning to implement 'evsl' instrinsic.
d = __ev_sl (a,b) : The value in parameter 'a' is shifted left by no.
of  bit positions specified in parameter 'b', filling vacated bit
positions with zeros, and the result is placed into parameter d.

My question: Is it better to have parameter 'b' of single scalar type
[int a] or vector type [__ev64_u64__ g = { 3 } ]?

Looking at _ev_slb, _ev_slh, _ev_slw, where a single scalar type will
not work since the shift amounts are carried by a "vector" of bytes,
half-words, and words respectively, for uniformity can we consider
64-bit shift as similar, a "vector" of one shift amount?

Thanks in advance.

Regards,
Rohit

Extension to compare-elim

[Paulo J. Matos]

Hi,

I am looking at a missed optimization and I think this is something that 
could be added to compare-elim, if it's not already done somewhere else. 
I have a double word comparison to zero, so in C it's:

int le(long a) { return a <= 0; }

My expand uses the following transformation (in my current discussion y0 
and y1 are 0):

   if x0:x1 <= y0:y1 goto L
==>
   if x0 < y0 goto L
   if x0 > y0 goto K
   if x1 <= y1 goto L
K:


This generates the assembler:
$le:
tst @$XAP_AH
bmi ?L7
cmp AH,#H'
bgt ?L3
tst @$XAP_AL
bne ?L3
?L7:
ld  AL,#H'0001
bra 0,X
?L3:
ld  AL,#H'
bra 0,X

My argument is that the tst @$XAP_AH above could be transformed into cmp 
AH, #H' and the following compare could be removed getting this:

$le:
cmp AH,#H'
bmi ?L7
bgt ?L3
tst @$XAP_AL
bne ?L3
?L7:
ld  AL,#H'0001
bra 0,X
?L3:
ld  AL,#H'
bra 0,X

The RTL for the first two comparisons at compare-elim is:
(insn 51 3 52 2 (set (reg:CC_NZ 13 CC)
(compare:CC_NZ (reg:QI 0 AH [orig:27 a ] [27])
(const_int 0 [0]))) b651.c:1 63 {*tstqi}
 (nil))

(jump_insn 52 51 34 2 (set (pc)
(if_then_else (ge (reg:CC_NZ 13 CC)
(const_int 0 [0]))
(label_ref 41)
(pc))) b651.c:1 68 {*conditional_branch}
 (expr_list:REG_BR_PROB (const_int 7900 [0x1edc])
(nil))
 -> 41)

(code_label 41 43 25 4 6 "" [1 uses])

(note 25 41 49 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(insn 49 25 50 4 (set (reg:CC 13 CC)
(compare:CC (reg:QI 0 AH [orig:27 a ] [27])
(const_int 0 [0]))) b651.c:1 64 {*cmpqi}
 (nil))

(jump_insn 50 49 26 4 (set (pc)
(if_then_else (gt (reg:CC 13 CC)
(const_int 0 [0]))
(label_ref 13)
(pc))) b651.c:1 68 {*conditional_branch}
 (expr_list:REG_BR_PROB (const_int 7900 [0x1edc])
(nil))
 -> 13)

The transformation would involve deleting insn 49 and transforming insn 
51 into mode CC. I guess this could be easily done by checking at each 
comparison if we can eliminate the current comparison by generalizing 
the previous one using a function like rx_cc_modes_compatible (from rx.c).


What do you think?

Cheers,

--
PMatos

Re: A question about loop ivopt

[Zdenek Dvorak]

Hi,

> > > > Why can't we replace function force_expr_to_var_cost directly with
> function
> > > > computation_cost in tree-ssa-loop-ivopt.c?
> > > >
> > > > Actually I think it is inaccurate for the current recursive algorithm
> in
> > > > force_expr_to_var_cost to estimate expr cost. Instead
> computation_cost can
> > > > count some back-end factors and make the estimation more accurate.
> > > >
> > > > For example, using computation_cost, we may check whether back-ends
> can tie
> > > > some modes transformation expressed by SUBREG or not. If we use
> > > > force_expr_to_var_cost, some more computations around type
> > > > promotion/demotion would increase the cost estimated.
> > > >
> > > > Looking at the algorithm in force_expr_to_var_cost, it is just to
> analyze
> > > > the operator in the expression and give estimation. Should it be the
> same as
> > > > expanding EXPR to RTX and give estimation like in computation_cost?
> > > >
> > > > Any thoughts?
> > >
> > > I suppose Zdenek may remember.
> >
> > computation_cost actually expands the expression to RTL.  Since cost
> estimates
> > are computed a lot in ivopts, using it directly would require a huge
> amount of memory,
> 
> Zdenek,
> 
> Do you know how huge is it? Any data on this? For GCC, is this "huge"
> memory consumption is critical enough, and there aren't any other else
> consuming even more memory?

no, not really (I haven't worked on this for a few years now), although
of course I did some measurements when ivopts were created.  Feel free
to experiment with that, if it turned out that the memory consumption
and extra time spent by it is negligible, it would be a nice cleanup.

Zdenek

Re: A question about loop ivopt

[Richard Guenther]

On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak  wrote:
> Hi,
>
>> > > > Why can't we replace function force_expr_to_var_cost directly with
>> function
>> > > > computation_cost in tree-ssa-loop-ivopt.c?
>> > > >
>> > > > Actually I think it is inaccurate for the current recursive algorithm
>> in
>> > > > force_expr_to_var_cost to estimate expr cost. Instead
>> computation_cost can
>> > > > count some back-end factors and make the estimation more accurate.
>> > > >
>> > > > For example, using computation_cost, we may check whether back-ends
>> can tie
>> > > > some modes transformation expressed by SUBREG or not. If we use
>> > > > force_expr_to_var_cost, some more computations around type
>> > > > promotion/demotion would increase the cost estimated.
>> > > >
>> > > > Looking at the algorithm in force_expr_to_var_cost, it is just to
>> analyze
>> > > > the operator in the expression and give estimation. Should it be the
>> same as
>> > > > expanding EXPR to RTX and give estimation like in computation_cost?
>> > > >
>> > > > Any thoughts?
>> > >
>> > > I suppose Zdenek may remember.
>> >
>> > computation_cost actually expands the expression to RTL.  Since cost
>> estimates
>> > are computed a lot in ivopts, using it directly would require a huge
>> amount of memory,
>>
>> Zdenek,
>>
>> Do you know how huge is it? Any data on this? For GCC, is this "huge"
>> memory consumption is critical enough, and there aren't any other else
>> consuming even more memory?
>
> no, not really (I haven't worked on this for a few years now), although
> of course I did some measurements when ivopts were created.  Feel free
> to experiment with that, if it turned out that the memory consumption
> and extra time spent by it is negligible, it would be a nice cleanup.

Well, I don't think we should feed arbitrary expressions to expand at
IVOPTs time.  What probably matters most is address costs, no?
At least that is where expand probably makes the most difference.
So why not improve force_expr_to_var_cost instead?

Richard.


> Zdenek

Re: [discuss] [x86-64 psABI] RFC: Extend x86-64 psABI to support x32

[Michael Matz]

Hi,

On Mon, 14 May 2012, H.J. Lu wrote:

> > As a minor nitpick, I have always used x32 with a lower case x.  The 
> > capital X32 looks odd to me.
> >
> 
> I used X32 together with LP64.  I can use ILP32 instead of X32 when LP64 
> is mentioned at the same time.

I'd prefer that.  x32 is a nice short-hand name for the whole thing, but 
not descriptive, unlike LP64.  So, yes, IMO it should be ILP32 in the ABI 
document.


Ciao,
Michael.

Re: [discuss] [x86-64 psABI] RFC: Extend x86-64 psABI to support x32

[H.J. Lu]

On Tue, May 15, 2012 at 9:07 AM, Michael Matz  wrote:
> Hi,
>
> On Mon, 14 May 2012, H.J. Lu wrote:
>
>> > As a minor nitpick, I have always used x32 with a lower case x.  The
>> > capital X32 looks odd to me.
>> >
>>
>> I used X32 together with LP64.  I can use ILP32 instead of X32 when LP64
>> is mentioned at the same time.
>
> I'd prefer that.  x32 is a nice short-hand name for the whole thing, but
> not descriptive, unlike LP64.  So, yes, IMO it should be ILP32 in the ABI
> document.
>

I will make the change and post a new patch.

Thanks.

-- 
H.J.

Re: Trying to track down a register allocation issue

[Paul_Koning]

On May 14, 2012, at 5:47 PM, Joern Rennecke wrote:

> Quoting paul_kon...@dell.com:
> 
>> I'm running into an ICE due to what looks like wrong register  allocation, 
>> and I'm trying to figure out where the problem lies.  It  shows up with 
>> today's GCC (trunk).  I haven't yet tried to narrow it  down to a particular 
>> change.
>> 
>> It shows up in the pdp11 target, -O2.  Not clear that this is pdp11 specific.
> 
> If a match test is confused with an overlap test somehwhere, the incidence
> would be influenced by the endianness.  The little-endian equivalent
> would be (reg:SI 2) versus (reg:HI 3).  Except that the latter wouldn't
> tend to be created by (misdirected) attempts to tie modes of different sizes.

Hm.  But pdp11.h says:
#define MODES_TIEABLE_P(MODE1, MODE2) 0
so it seems that tying modes of different sizes should not be happening here.  
Also, I don't see reg:SI 2 vs. reg:HI 3, I see reg:SI 2 vs. reg:HI 2.  So the 
overlap is explicit, it doesn't depend on endians or mode sizes.

> And of course you have a word size factor here; on a 32 or 64 bit target,
> you need larger modes to get multi-hard-register pseudos.

paul

Re: Build problem with libgo runtime

[Ian Lance Taylor]

"William J. Schmidt"  writes:

> I'm investigating another build failure for Fedora 17 (based on 4.7).
> The failing compile from the build log is as follows:
>
> /bin/sh ./libtool  --tag=CC
> --mode=compile 
> /builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/xgcc 
> -B/builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/ 
> -B/usr/ppc64-redhat-linux/bin/ -B/usr/ppc64-redhat-linux/lib/ -isystem 
> /usr/ppc64-redhat-linux/include -isystem /usr/ppc64-redhat-linux/sys-include  
>   -DHAVE_CONFIG_H -I. -I../../../libgo  -I ../../../libgo/runtime 
> -I../../../libgo/../libffi/include -I../libffi/include -pthread  -fexceptions 
> -fplan9-extensions  -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror  
> -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I 
> ../../../libgo/../libgcc -I ../../gcc/include -O2 -O3 -mtune=power7 
> -mcpu=power7 -g -fsigned-char -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c -o 
> proc.lo `test -f 'runtime/proc.c' || echo '../../../libgo/'`runtime/proc.c
>
> The reported failure:
>
> ../../../libgo/runtime/proc.c: In function ‘__go_go’:
> ../../../libgo/runtime/proc.c:1323:8: error: variable ‘sp’ might be
> clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
> ../../../libgo/runtime/proc.c:1324:9: error: variable ‘spsize’ might be
> clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
> cc1: all warnings being treated as errors
>
> The declarations in question are:
>
>   byte *sp;
>   size_t spsize;
>   G * volatile newg;  // volatile to avoid longjmp warning
>
> What's interesting here is that I don't see a problem when compiling for
> a 32-bit target.  However, it's also apparent that making "newg"
> volatile was deemed sufficient up till now, so I am wondering if there
> is something about our build options/environment that could cause the
> problem.
>
> I can work around the problem with the following patch, but would
> appreciate any insights into whether this should be necessary, and if
> not, what we're doing "wrong."


I don't know why you are seeing this when I am not.  However, the
warning is essentially correct.  It's not useful, because as it happens
nothing will ever call setcontext in such a way that the getcontext call
will return a second time, but the compiler can't know that.  And if it
did happen, the warning would be valid.  So I committed this variant of
your patch to prevent the warning.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline and 4.7 branch.

Ian

diff -r efd2462cb004 libgo/runtime/proc.c
--- a/libgo/runtime/proc.c	Mon May 14 14:57:59 2012 -0700
+++ b/libgo/runtime/proc.c	Tue May 15 11:54:04 2012 -0700
@@ -1322,7 +1322,7 @@
 {
 	byte *sp;
 	size_t spsize;
-	G * volatile newg;	// volatile to avoid longjmp warning
+	G *newg;
 
 	schedlock();
 
@@ -1363,19 +1363,26 @@
 	if(sp == nil)
 		runtime_throw("nil g->stack0");
 
-	getcontext(&newg->context);
-	newg->context.uc_stack.ss_sp = sp;
+	{
+		// Avoid warnings about variables clobbered by
+		// longjmp.
+		byte * volatile vsp = sp;
+		size_t volatile vspsize = spsize;
+		G * volatile vnewg = newg;
+
+		getcontext(&vnewg->context);
+		vnewg->context.uc_stack.ss_sp = vsp;
 #ifdef MAKECONTEXT_STACK_TOP
-	newg->context.uc_stack.ss_sp += spsize;
+		vnewg->context.uc_stack.ss_sp += vspsize;
 #endif
-	newg->context.uc_stack.ss_size = spsize;
-	makecontext(&newg->context, kickoff, 0);
+		vnewg->context.uc_stack.ss_size = vspsize;
+		makecontext(&vnewg->context, kickoff, 0);
 
-	newprocreadylocked(newg);
-	schedunlock();
+		newprocreadylocked(vnewg);
+		schedunlock();
 
-	return newg;
-//printf(" goid=%d\n", newg->goid);
+		return vnewg;
+	}
 }
 
 // Put on gfree list.  Sched must be locked.

How do I set SIG_ATOMIC_TYPE to a variant of a C-type?

[Hans-Peter Nilsson]

I'm considering changing SIG_ATOMIC_TYPE for CRIS (*-elf and
*-linux-gnu) to the effect of
 #define SIG_ATOMIC_TYPE "int __attribute__((__aligned__(4)))"
but that by itself doesn't work.  It causes a SEGV on the 4.7
branch and no doubt also on trunk; the code is the same.  From a
gdb session it appears the type is expected to already exist as
a built-in C type, like the (undecorated) "int" or "char" types,
which are created much earlier in the same function.

How do I accomplish setting SIG_ATOMIC_TYPE as above?

Ok, someone is going to ask "why": in the ABI used for CRIS, all
types have byte alignment; structs are "packed".  Linux could
(AFAIU, theoretically) perform a context-switch if a process
gets a page-fault writing to a "sigatomic_t" plain "int" that's
straddling a page boundary where one of the pages isn't present
(say, not yet in the TLB, or paged out).  When the process gets
to execute again, a signal could be waiting (say, SIGALRM) and
the signal handler entered, but that plain "int" is not written
in whole; presto, the access not atomic as seen by the
signal-handler.  (In case of a very possible thinko here, please
don't forget the first question.)

brgds, H-P

Re: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?

[Joseph S. Myers]

On Tue, 15 May 2012, Hans-Peter Nilsson wrote:

> How do I accomplish setting SIG_ATOMIC_TYPE as above?

GCC only needs to know this type for the purposes of defining limits for 
stdint.h.  Unless your signal.h does

typedef __SIG_ATOMIC_TYPE__ sig_atomic_t;

this should only affect the testcases gcc.dg/c99-stdint-[56].c, not actual 
user code.  And as you have discovered, there are rules for these type 
strings documented in tm.texi under SIZE_TYPE; to use some other variant 
you'll need to find and eliminate all the dependencies on whatever rule 
you wish to change.

Logically these macros should be hooks returning enumeration values from a 
defined set of possible types, not strings at all.  See past discussions 
with Joern, e.g.  
and .

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?

[Hans-Peter Nilsson]

> From: "Joseph S. Myers" 
> Date: Tue, 15 May 2012 22:06:03 +0200

> Unless your signal.h does
> 
> typedef __SIG_ATOMIC_TYPE__ sig_atomic_t;

I just assumed that was the case, what with other ___xxx_TYPE__
being used throughout the test-suite.  My bad.

> this should only affect the testcases gcc.dg/c99-stdint-[56].c, not actual 
> user code.  And as you have discovered, there are rules for these type 
> strings documented in tm.texi under SIZE_TYPE; to use some other variant 
> you'll need to find and eliminate all the dependencies on whatever rule 
> you wish to change.

What I missed was more careful reading, the clue being: "The
string must exactly match one of the data type names defined in
the function..."  Hah, there you go, thanks and sorry for the
noise.

brgds, H-P