RE: mips64vr-elf fails to build
Hi Nick,
Many thanks for reporting this. This has previously been reported as pr56942
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56942). A patch has been
submitted to fix this. Please see:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01173.html.
Regards,
Andrew
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Nick Clifton
> Sent: 21 April 2013 12:08
> To: echri...@gmail.com; rdsandif...@googlemail.com
> Cc: gcc@gcc.gnu.org
> Subject: mips64vr-elf fails to build
>
> Hi Eric, Hi Richard,
>
> The mips64vr-elf target currently fails to build in FSF mainline
> because:
>
> libgcc/unwind-dw2.c:1159:1: internal compiler error: in output_555, at
> config/mips/mips.md:6024
>
> which is here:
>
> (define_insn "casesi_internal_mips16_"
> [(set (pc)
>(if_then_else
> (leu (match_operand:SI 0 "register_operand" "d")
> (match_operand:SI 1 "arith_operand" "dI"))
> (unspec:P
> [(match_dup 0)
> (label_ref (match_operand 2 "" ""))]
> UNSPEC_CASESI_DISPATCH)
> (label_ref (match_operand 3 "" ""
> (clobber (match_scratch:P 4 "=d"))
> (clobber (match_scratch:P 5 "=d"))
> (clobber (reg:SI MIPS16_T_REGNUM))]
> "TARGET_MIPS16_SHORT_JUMP_TABLES"
> {
> rtx diff_vec = PATTERN (next_real_insn (operands[2]));
>
> => gcc_assert (GET_CODE (diff_vec) == ADDR_DIFF_VEC);
>
> I am not sure of the best way to fix this, so I am punting to you
> guys. :-)
>
> Cheers
> Nick
>
Re: Failure building current snapshot [Cygwin]
Il 16/04/2013 10.10, Dave Korn ha scritto:
On 15/04/2013 15:50, Angelo Graziosi wrote:
The current snapshot [*] fails to build on Cygwin as follow:
/work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
error: unrecognizable insn:
}
^
(insn 15 14 16 5 (set (reg:SI 63)
(symbol_ref:SI ("GetModuleHandleA@4") [flags 0x441]
))
/work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:109 -1
(nil))
/work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
internal compiler error: in extract_insn, at recog.c:2150
/work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
internal compiler error: Aborted
xgcc: internal compiler error: Aborted (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975
From comment 5 and 9 something should be fixed but with current
snapshot, 4.9-20130421, it seems that the build fails in the same way:
[...]
if test -z "$objects"; then \
echo 'int __libgcc_eh_dummy;' > eh_dummy.c;\
/work/gcc-4.9-20130421/Work/./gcc/xgcc
-B/work/gcc-4.9-20130421/Work/./gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
/usr/local/gfortran/i686-pc-cygwin/include -isystem
/usr/local/gfortran/i686-pc-cygwin/sys-include-g -O2 -O2
-I/work/gcc-4.9-20130421/libgcc/../winsup/w32api/include
-I/work/gcc-4.9-20130421/libgcc/../winsup/include
-I/work/gcc-4.9-20130421/libgcc/../winsup/cygwin/include -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include-g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I.
-I../.././gcc -I/work/gcc-4.9-20130421/libgcc
-I/work/gcc-4.9-20130421/libgcc/. -I/work/gcc-4.9-20130421/libgcc/../gcc
-I/work/gcc-4.9-20130421/libgcc/../include
-I/work/gcc-4.9-20130421/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_EMUTLS -c eh_dummy.c \
-o eh_dummy.o; \
objects=eh_dummy.o; \
fi; \
ar rc libgcc.a $objects
ranlib libgcc.a
/work/gcc-4.9-20130421/libgcc/config/i386/cygming-crtbegin.c: In
function ‘__gcc_register_frame’:
/work/gcc-4.9-20130421/libgcc/config/i386/cygming-crtbegin.c:106:19:
warning: array subscript is above array bounds [-Warray-bounds]
if (__JCR_LIST__[0])
^
/work/gcc-4.9-20130421/libgcc/config/i386/cygming-crtbegin.c:120:1:
error: unrecognizable insn:
}
^
(insn 15 14 16 5 (set (reg:SI 63)
(symbol_ref:SI ("GetModuleHandleA@4") [flags 0x441]
))
/work/gcc-4.9-20130421/libgcc/config/i386/cygming-crtbegin.c:109 -1
(nil))
/work/gcc-4.9-20130421/libgcc/config/i386/cygming-crtbegin.c:120:1:
internal compiler error: in extract_insn, at recog.c:2150
/work/gcc-4.9-20130421/libgcc/config/i386/cygming-crtbegin.c:120:1:
internal compiler error: Aborted
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
/work/gcc-4.9-20130421/libgcc/config/i386/t-cygming:9: recipe for target
`crtbegin.o' failed
make[2]: *** [crtbegin.o] Error 4
make[2]: uscita dalla directory
"/work/gcc-4.9-20130421/Work/i686-pc-cygwin/libgcc"
Makefile:10678: recipe for target `all-target-libgcc' failed
make[1]: *** [all-target-libgcc] Error 2
make[1]: uscita dalla directory "/work/gcc-4.9-20130421/Work"
Makefile:857: recipe for target `all' failed
make: *** [all] Error 2
I have configured with:
PATH_TO/configure --prefix=/usr/local/gfortran --program-suffix=-4.9
--enable-languages=c,c++,fortran --enable-checking=release
--enable-threads=posix --enable-libgomp --with-arch=native
--with-tune=native --with-fpmath=sse --disable-bootstrap
--disable-libmudflap --disable-shared
(cygwin-1.7.18)
Ciao,
Angelo.
Re: Failure building current snapshot [Cygwin]
On 22/04/2013 13:51, Angelo Graziosi wrote: > Il 16/04/2013 10.10, Dave Korn ha scritto: >>This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 > > > From comment 5 and 9 something should be fixed but with current > snapshot, 4.9-20130421, it seems that the build fails in the same way: Nothing's been checked in yet. Tests look good though, so we should be able to proceed soon. cheers, DaveK
Re: Failure building current snapshot [Cygwin]
Il 22/04/2013 15.03, Dave Korn ha scritto: On 22/04/2013 13:51, Angelo Graziosi wrote: Il 16/04/2013 10.10, Dave Korn ha scritto: This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 From comment 5 and 9 something should be fixed but with current snapshot, 4.9-20130421, it seems that the build fails in the same way: Nothing's been checked in yet. Tests look good though, so we should be able to proceed soon. Ah, sorry for the noise then.. Ciao, Angelo.
You`re Getting It Early!
Could SC_X_N be the future acquisition prospect for British Petroleum? British Petroleum dedicated 40 Billion cleaning it's last oil leakage. What amount can BP invest to minimize that 40 Billion expense, reduce pollution to the planet and corporate image? Scout Exploration Inc provides a new and needed tool for oil spill solution. Trade SC_X_N before it reaches it's business value grab shares below dollar on Apr, 22nd!
Re: [lambda] Latest experimental polymorphic lambda patches
On 08/10/2009 08:33 PM, Adam Butcher wrote: Attached are my latest experimental polymorphic lambda patches against the latest lambda branch. Polymorphic lambdas were voted in for C++14 at the meeting this past week; are you interested in resuming this work? The proposal will be at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html once the post-meeting mailing is released, or I can send you a copy if you'd like to see it sooner. Jason
History question: Thread-safe profiling instrumentation
Six years ago, Michael Matz proposed a patch for generating profile instrumentation in a thread-safe manner: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html Reading through the thread, I saw a few minor objections, but nothing to indicate the patch should be withdrawn. However, apparently the changes were never made. I'm curious about the history here. What was the reason for abandoning this? Was a better alternative found? Were all the counters made thread-local? My reason for asking involves a large heavily-threaded application that is improved by feedback-directed optimization on some platforms, but not on others. One theory is that a defective profile is generated due to counter dropouts from contention. I'm somewhat skeptical about this given that some platforms seem to do well with it, but it's possible. I'm hopeful that knowing why the thread-safe profiling patch wasn't implemented will give us more of a clue. Thanks for any help! Bill
Re: History question: Thread-safe profiling instrumentation
There is a similar patch (in google branches) from Rong Xu which enables atomic profile counter update. http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00072.html On Mon, Apr 22, 2013 at 12:59 PM, Bill Schmidt wrote: > Six years ago, Michael Matz proposed a patch for generating profile > instrumentation in a thread-safe manner: > > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html > > Reading through the thread, I saw a few minor objections, but nothing to > indicate the patch should be withdrawn. However, apparently the changes > were never made. > > I'm curious about the history here. What was the reason for abandoning > this? Was a better alternative found? Were all the counters made > thread-local? > > My reason for asking involves a large heavily-threaded application that > is improved by feedback-directed optimization on some platforms, but not > on others. One theory is that a defective profile is generated due to > counter dropouts from contention. I'm somewhat skeptical about this > given that some platforms seem to do well with it, but it's possible. Do you see lots of messages about insane profile data (under -fprofile-correction)? Most of the such messages we see (in our large multi-threaded applications) show only marginal errors. > I'm hopeful that knowing why the thread-safe profiling patch wasn't > implemented will give us more of a clue. You can try out Rong's patch. He plan to submit it to trunk soon. thanks, David > > Thanks for any help! > > Bill >
Re: History question: Thread-safe profiling instrumentation
On Mon, 2013-04-22 at 13:13 -0700, Xinliang David Li wrote: > There is a similar patch (in google branches) from Rong Xu which > enables atomic profile counter update. > > http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00072.html Thanks, David! We'll take a look. > > On Mon, Apr 22, 2013 at 12:59 PM, Bill Schmidt > wrote: > > Six years ago, Michael Matz proposed a patch for generating profile > > instrumentation in a thread-safe manner: > > > > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html > > > > Reading through the thread, I saw a few minor objections, but nothing to > > indicate the patch should be withdrawn. However, apparently the changes > > were never made. > > > > I'm curious about the history here. What was the reason for abandoning > > this? Was a better alternative found? Were all the counters made > > thread-local? > > > > My reason for asking involves a large heavily-threaded application that > > is improved by feedback-directed optimization on some platforms, but not > > on others. One theory is that a defective profile is generated due to > > counter dropouts from contention. I'm somewhat skeptical about this > > given that some platforms seem to do well with it, but it's possible. > > Do you see lots of messages about insane profile data (under > -fprofile-correction)? Most of the such messages we see (in our large > multi-threaded applications) show only marginal errors. > We're still waiting on that data. We don't have direct access to the application so we're having to work at some remove. When we asked for it the first time, the build logs had unfortunately been purged. > > > I'm hopeful that knowing why the thread-safe profiling patch wasn't > > implemented will give us more of a clue. > > You can try out Rong's patch. He plan to submit it to trunk soon. Much obliged! Bill > > thanks, > > David > > > > > Thanks for any help! > > > > Bill > > >
Re: Delay slot filling - what still matters, and what doesn't matter so much anymore?
On Sun, Apr 21, 2013 at 11:50 PM, Jeff Law wrote:
> The 60% number also tells me there'd be a lot to be gained by using the
> scheduler's dependency information to drive filling. We'd end up looking at
> far fewer insns.
FWIW I haven't had much time to hack my sched-dbr.c much, but attached
is the latest copy of it. Stats on my collection of cc1-i files:
$ for d in nodelay/ reorg/ dbr/ ; do grep -w nop ${d}/* | wc ; done
383532 767091 10550413
164616 329259 4185216
179938 359903 4217429
where nodelay is -fno-delayed-branch, reorg is current reorg.c but
with annulling disabled, and dbr is this sched-dbr.c.
It's obviously far from complete, it's not even in "toy" maturity :-)
For one thing, annulling branches are not handled at all yet. Other
things where it fails:
* memory ops in call delay slots:
@@ -7414,8 +7402,9 @@
ldx [%l4+%lo(valvar_pool)], %o0
.L:
stx %g1, [%fp+2039]
+ stx %g2, [%fp+2031]
callpool_alloc, 0
-stx%g2, [%fp+2031]
+nop
stb %g0, [%o0+12]
stx %i4, [%o0]
ldx [%fp+2031], %g2
...
@@ -7579,8 +7567,9 @@
ldx [%fp+2039], %o1
callhtab_find_with_hash, 0
srl%o2, 0, %o2
+ stx %o0, [%fp+2031]
brz,pn %o0, .L
-stx%o0, [%fp+2031]
+nop
.L:
ldx [%fp+2039], %g1
brz,pn %g1, .L
* funny things with returns that look wrong to me but haven't had time
to look into:
@@ -7950,9 +7939,8 @@
ldx [%i3], %o1
ldx [%g4+32], %o0
callnotify_dependents_of_resolved_value.isra.46, 0
-mov%l7, %i0
- return %i7+8
-nop
+jmp%i7+8
+restore %g0, %l7, %o0
.L:
ldx [%fp+2039], %g2
ldx [%g2+8], %g1
* picking insns from after the delay insn:
@@ -18,9 +18,9 @@
sra %i5, 0, %g1
add %g1, 2, %g1
sllx%g1, 3, %g1
- ldx [%i4+%g1], %g1
call%g1, 0
-add%i5, -1, %i5
+ldx[%i4+%g1], %g1
+ add %i5, -1, %i5
cmp %i5, -1
bne,pt %icc, .L
nop
OTOH it also already successfully finds opportunities that reorg.c
doesn't see, e.g.:
sub%i4, %i5, %i3 sub %i4, %i5, %i3
mov%o0, %i1 mov %o0, %i1
sub%i2, %i3, %i5 <
call bar, 0callbar, 0
mov%i3, %o0 mov%i3, %o0
ba,pt %xcc, .L6 | ba,pt %xcc, .L2
cmp%i4, %i2 |sub%i2, %i3, %i5
reorg.c takes the cmp from the target but sched-dbr looks through the
call to find the sub.
Ciao!
Steven
/* Perform delay slot filling.
Copyright (C) 2013 Free Software Foundation, Inc.
Contributed by Steven Bosscher.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3. If not see
Simple PHI question
I have a basic GCC PHI implementation question, if a basic block has a phi node (or a set of phi nodes) those nodes consist of a pairs of definitions and basic block pointers. Are the basic blocks associated with each definition gauranteed to be direct predecessors of the block containing the phi node? Or could the block with the definition be an indirect predecessor of the block with the phi? Does it matter what pass in the compiler I am at? I.e. maybe they start out as direct predecessors and various optimizations could change that. Steve Ellcey sell...@imgtec.com
Re: History question: Thread-safe profiling instrumentation
Bill Schmidt writes: > > My reason for asking involves a large heavily-threaded application that > is improved by feedback-directed optimization on some platforms, but not > on others. One theory is that a defective profile is generated due to > counter dropouts from contention. I'm somewhat skeptical about this > given that some platforms seem to do well with it, but it's possible. > I'm hopeful that knowing why the thread-safe profiling patch wasn't > implemented will give us more of a clue. Atomics are slower even single threaded. In any case you'll have a gigantic slowdown if there is contention. Better use per thread counters. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: Simple PHI question
On Mon, Apr 22, 2013 at 3:10 PM, Steve Ellcey wrote: > I have a basic GCC PHI implementation question, if a basic block has > a phi node (or a set of phi nodes) those nodes consist of a pairs of > definitions and basic block pointers. Are the basic blocks associated > with each definition gauranteed to be direct predecessors of the block > containing the phi node? Or could the block with the definition be an > indirect predecessor of the block with the phi? Does it matter what > pass in the compiler I am at? I.e. maybe they start out as direct > predecessors and various optimizations could change that. They should always be direct predecessors of the basic block of the PHI node. If it is not then there is a bug. Thanks, Andrew Pinski > > Steve Ellcey > sell...@imgtec.com >
Re: History question: Thread-safe profiling instrumentation
On Mon, Apr 22, 2013 at 3:19 PM, Andi Kleen wrote: > Bill Schmidt writes: >> >> My reason for asking involves a large heavily-threaded application that >> is improved by feedback-directed optimization on some platforms, but not >> on others. One theory is that a defective profile is generated due to >> counter dropouts from contention. I'm somewhat skeptical about this >> given that some platforms seem to do well with it, but it's possible. >> I'm hopeful that knowing why the thread-safe profiling patch wasn't >> implemented will give us more of a clue. > > Atomics are slower even single threaded. In any case you'll have a > gigantic slowdown if there is contention. Better use per thread > counters. Actually it depends on the processor. For an example on Octeon2, the atomic addition is faster than non atomic addition as the atomic instructions work on L2 rather than working going through L1 and then to L2. Basically the atomic addition of a counter does not have to populate the L1 cache in this case. Thanks, Andrew Pinski > > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only
Re: LRA assign same hard register with live range overlapped pseduos
On 13-04-22 2:26 AM, Shiva Chen wrote:
Hi, Vladimir
I write the new patch as your suggestion.
Could you help me to check is there something missing ?
I think there is one more place to use lra_assign_reg_val:
lra.c::lra_create_new_reg
Please add the code and right changelog entry for the patch and you can
commit the patch into trunk.
Thanks, Shiva.
Thanks, Shiva
gcc/lra-assigns.c | 12 +++-
gcc/lra-constraints.c |5 ++---
gcc/lra-eliminations.c | 10 --
gcc/lra-int.h | 33 +
gcc/lra.c |1 +
5 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/gcc/lra-assigns.c b/gcc/lra-assigns.c
index b204513..3f8a899 100644
--- a/gcc/lra-assigns.c
+++ b/gcc/lra-assigns.c
@@ -448,7 +448,7 @@ find_hard_regno_for (int regno, int *cost, int
try_only_hard_regno)
int hr, conflict_hr, nregs;
enum machine_mode biggest_mode;
unsigned int k, conflict_regno;
- int val, biggest_nregs, nregs_diff;
+ int offset, val, biggest_nregs, nregs_diff;
enum reg_class rclass;
bitmap_iterator bi;
bool *rclass_intersect_p;
@@ -508,9 +508,10 @@ find_hard_regno_for (int regno, int *cost, int
try_only_hard_regno)
#endif
sparseset_clear_bit (conflict_reload_and_inheritance_pseudos, regno);
val = lra_reg_info[regno].val;
+ offset = lra_reg_info[regno].offset;
CLEAR_HARD_REG_SET (impossible_start_hard_regs);
EXECUTE_IF_SET_IN_SPARSESET (live_range_hard_reg_pseudos, conflict_regno)
-if (val == lra_reg_info[conflict_regno].val)
+if (lra_reg_val_equal_p (conflict_regno, val, offset))
{
conflict_hr = live_pseudos_reg_renumber[conflict_regno];
nregs = (hard_regno_nregs[conflict_hr]
@@ -538,7 +539,7 @@ find_hard_regno_for (int regno, int *cost, int
try_only_hard_regno)
}
EXECUTE_IF_SET_IN_SPARSESET (conflict_reload_and_inheritance_pseudos,
conflict_regno)
-if (val != lra_reg_info[conflict_regno].val)
+if (!lra_reg_val_equal_p (conflict_regno, val, offset))
{
lra_assert (live_pseudos_reg_renumber[conflict_regno] < 0);
if ((hard_regno
@@ -1007,7 +1008,7 @@
setup_live_pseudos_and_spill_after_risky_transforms (bitmap
{
int p, i, j, n, regno, hard_regno;
unsigned int k, conflict_regno;
- int val;
+ int val, offset;
HARD_REG_SET conflict_set;
enum machine_mode mode;
lra_live_range_t r;
@@ -1050,8 +1051,9 @@
setup_live_pseudos_and_spill_after_risky_transforms (bitmap
COPY_HARD_REG_SET (conflict_set, lra_no_alloc_regs);
IOR_HARD_REG_SET (conflict_set, lra_reg_info[regno].conflict_hard_regs);
val = lra_reg_info[regno].val;
+ offset = lra_reg_info[regno].offset;
EXECUTE_IF_SET_IN_SPARSESET (live_range_hard_reg_pseudos,
conflict_regno)
- if (val != lra_reg_info[conflict_regno].val
+ if (!lra_reg_val_equal_p (conflict_regno, val, offset)
/* If it is multi-register pseudos they should start on
the same hard register. */
|| hard_regno != reg_renumber[conflict_regno])
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index e3b4add..2a72aef 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -704,7 +704,7 @@ match_reload (signed char out, signed char *ins,
enum reg_class goal_class,
pseudos still live where reload pseudos dies. */
if (REG_P (in_rtx) && (int) REGNO (in_rtx) < lra_new_regno_start
&& find_regno_note (curr_insn, REG_DEAD, REGNO (in_rtx)))
- lra_reg_info[REGNO (reg)].val = lra_reg_info[REGNO (in_rtx)].val;
+ lra_assign_reg_val (REGNO (in_rtx), REGNO (reg));
}
else
{
@@ -733,8 +733,7 @@ match_reload (signed char out, signed char *ins,
enum reg_class goal_class,
&& GET_MODE (subreg_reg) == outmode
&& SUBREG_BYTE (in_rtx) == SUBREG_BYTE (new_in_reg)
&& find_regno_note (curr_insn, REG_DEAD, REGNO (subreg_reg)))
- lra_reg_info[REGNO (reg)].val
- = lra_reg_info[REGNO (subreg_reg)].val;
+ lra_assign_reg_val (REGNO (subreg_reg), REGNO (reg));
}
}
}
diff --git a/gcc/lra-eliminations.c b/gcc/lra-eliminations.c
index 9df0bae..0e75cc2 100644
--- a/gcc/lra-eliminations.c
+++ b/gcc/lra-eliminations.c
@@ -1124,8 +1124,14 @@ update_reg_eliminate (bitmap insns_with_changed_offsets)
setup_elimination_map ();
for (ep = reg_eliminate; ep < ®_eliminate[NUM_ELIMINABLE_REGS]; ep++)
if (elimination_map[ep->from] == ep && ep->previous_offset != ep->offset)
- bitmap_ior_into (insns_with_changed_offsets,
- &lra_reg_info[ep->from].insn_bitmap);
+ {
+ bitmap_ior_into (insns_with_changed_offsets,
+&lra_reg_info[ep->from].insn_bitmap);
+
+ /* Update offset when the eliminate offset have been
Re: LRA assign same hard register with live range overlapped pseduos
Hi, Vladimir
I add the code and the patch has passed bootstrap/regression test
on i686-pc-linux-gnu with current main trunk.
However, I don't have svn write access yet.
Could you please help to commit this patch?
Thanks for your comment and your help. I really appreciate it.
A plaintext gcc/ChangeLog is as below:
2013-04-23 Shiva Chen
* lra-assigns.c (find_hard_regno_for): Use lra_reg_val_equal_p
to check the register content is equal or not.
* lra-constraints.c (match_reload): Use lra_assign_reg_val
to assign register content record.
* lra-eliminations.c (update_reg_eliminate): Use lra_set_up_reg_val
to update register content offset.
* lra-int.h (struct lra_reg): Add offset member.
(lra_reg_val_equal_p): New static inline function.
(lra_set_up_reg_val): New static inline function.
(lra_assign_reg_val): New static inline function.
* lra.c (lra_create_new_reg): Use lra_assign_reg_val
to assign register content record.
(initialize_lra_reg_info_element): Initial offset to zero
2013/4/23 Vladimir Makarov :
> On 13-04-22 2:26 AM, Shiva Chen wrote:
>>
>> Hi, Vladimir
>>
>> I write the new patch as your suggestion.
>> Could you help me to check is there something missing ?
>
> I think there is one more place to use lra_assign_reg_val:
>
> lra.c::lra_create_new_reg
>
> Please add the code and right changelog entry for the patch and you can
> commit the patch into trunk.
>
> Thanks, Shiva.
>
>> Thanks, Shiva
>>
>> gcc/lra-assigns.c | 12 +++-
>> gcc/lra-constraints.c |5 ++---
>> gcc/lra-eliminations.c | 10 --
>> gcc/lra-int.h | 33 +
>> gcc/lra.c |1 +
>> 5 files changed, 51 insertions(+), 10 deletions(-)
>>
>> diff --git a/gcc/lra-assigns.c b/gcc/lra-assigns.c
>> index b204513..3f8a899 100644
>> --- a/gcc/lra-assigns.c
>> +++ b/gcc/lra-assigns.c
>> @@ -448,7 +448,7 @@ find_hard_regno_for (int regno, int *cost, int
>> try_only_hard_regno)
>> int hr, conflict_hr, nregs;
>> enum machine_mode biggest_mode;
>> unsigned int k, conflict_regno;
>> - int val, biggest_nregs, nregs_diff;
>> + int offset, val, biggest_nregs, nregs_diff;
>> enum reg_class rclass;
>> bitmap_iterator bi;
>> bool *rclass_intersect_p;
>> @@ -508,9 +508,10 @@ find_hard_regno_for (int regno, int *cost, int
>> try_only_hard_regno)
>> #endif
>> sparseset_clear_bit (conflict_reload_and_inheritance_pseudos, regno);
>> val = lra_reg_info[regno].val;
>> + offset = lra_reg_info[regno].offset;
>> CLEAR_HARD_REG_SET (impossible_start_hard_regs);
>> EXECUTE_IF_SET_IN_SPARSESET (live_range_hard_reg_pseudos,
>> conflict_regno)
>> -if (val == lra_reg_info[conflict_regno].val)
>> +if (lra_reg_val_equal_p (conflict_regno, val, offset))
>> {
>> conflict_hr = live_pseudos_reg_renumber[conflict_regno];
>> nregs = (hard_regno_nregs[conflict_hr]
>> @@ -538,7 +539,7 @@ find_hard_regno_for (int regno, int *cost, int
>> try_only_hard_regno)
>> }
>> EXECUTE_IF_SET_IN_SPARSESET (conflict_reload_and_inheritance_pseudos,
>> conflict_regno)
>> -if (val != lra_reg_info[conflict_regno].val)
>> +if (!lra_reg_val_equal_p (conflict_regno, val, offset))
>> {
>> lra_assert (live_pseudos_reg_renumber[conflict_regno] < 0);
>> if ((hard_regno
>> @@ -1007,7 +1008,7 @@
>> setup_live_pseudos_and_spill_after_risky_transforms (bitmap
>> {
>> int p, i, j, n, regno, hard_regno;
>> unsigned int k, conflict_regno;
>> - int val;
>> + int val, offset;
>> HARD_REG_SET conflict_set;
>> enum machine_mode mode;
>> lra_live_range_t r;
>> @@ -1050,8 +1051,9 @@
>> setup_live_pseudos_and_spill_after_risky_transforms (bitmap
>> COPY_HARD_REG_SET (conflict_set, lra_no_alloc_regs);
>> IOR_HARD_REG_SET (conflict_set,
>> lra_reg_info[regno].conflict_hard_regs);
>> val = lra_reg_info[regno].val;
>> + offset = lra_reg_info[regno].offset;
>> EXECUTE_IF_SET_IN_SPARSESET (live_range_hard_reg_pseudos,
>> conflict_regno)
>> - if (val != lra_reg_info[conflict_regno].val
>> + if (!lra_reg_val_equal_p (conflict_regno, val, offset)
>> /* If it is multi-register pseudos they should start on
>> the same hard register. */
>> || hard_regno != reg_renumber[conflict_regno])
>> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
>> index e3b4add..2a72aef 100644
>> --- a/gcc/lra-constraints.c
>> +++ b/gcc/lra-constraints.c
>> @@ -704,7 +704,7 @@ match_reload (signed char out, signed char *ins,
>> enum reg_class goal_class,
>> pseudos still live where reload pseudos dies. */
>>if (REG_P (in_rtx) && (int) REGNO (in_rtx) <
>> lra_new_regno_start
>>&& find_regno_note (curr_insn, REG_DEAD, REGNO (in_rtx)))
