| Message ID | 20131121170912.GG3403@virgil.suse |
|---|---|
| State | New |
| Headers | show |
On Thu, Nov 21, 2013 at 5:09 PM, Martin Jambor <mjambor@suse.cz> wrote: > Hi, > > the patch below enables IRA live-range splitting that later > facilitates shrink-wrapping also work on ppc64. The difference is > that while on x86_64 it was enough to look for single sets from a hard > register to a pseudo in the first BB, on ppc the instructions are more > complicated and can look like this (example from pr10474.c testcase): > > (insn 6 3 7 2 (parallel [ > (set (reg:CC 124) > (compare:CC (reg:DI 3 3 [ i ]) > (const_int 0 [0]))) > (set (reg/v/f:DI 123 [ i ]) > (reg:DI 3 3 [ i ])) > ]) pr10474.c:6 428 {*movdi_internal2} > (expr_list:REG_DEAD (reg:DI 3 3 [ i ]) > (nil))) IIUC if this is the pattern you are detecting, this should help AArch32 in ARM state as well in the testcases you have attached particular case especially as this sort of rtl insn what we'd generate in this testcase (except ofcourse in SImode.) Is there any reason why these tests are so restricted to lp64 only targets ? ramana
Hi, On Thu, Nov 21, 2013 at 05:55:21PM +0000, Ramana Radhakrishnan wrote: > On Thu, Nov 21, 2013 at 5:09 PM, Martin Jambor <mjambor@suse.cz> wrote: > > Hi, > > > > the patch below enables IRA live-range splitting that later > > facilitates shrink-wrapping also work on ppc64. The difference is > > that while on x86_64 it was enough to look for single sets from a hard > > register to a pseudo in the first BB, on ppc the instructions are more > > complicated and can look like this (example from pr10474.c testcase): > > > > (insn 6 3 7 2 (parallel [ > > (set (reg:CC 124) > > (compare:CC (reg:DI 3 3 [ i ]) > > (const_int 0 [0]))) > > (set (reg/v/f:DI 123 [ i ]) > > (reg:DI 3 3 [ i ])) > > ]) pr10474.c:6 428 {*movdi_internal2} > > (expr_list:REG_DEAD (reg:DI 3 3 [ i ]) > > (nil))) > > IIUC if this is the pattern you are detecting, this should help > AArch32 in ARM state as well in the testcases you have attached > particular case especially as this sort of rtl insn what we'd generate > in this testcase (except ofcourse in SImode.) Is there any reason why > these tests are so restricted to lp64 only targets ? The reason why lp64 is necessary on x86_64 is that otherwise the dump scans would fail with -m32 because of ABI differences (parameters are not passed in registers and so the transformation does not happen). I have added it to the ppc case because that is what I have tested (and AFAIK, the 32-bit Linux ABI is also somehow different). If the testcases pass on any other target, I'll be grateful if you enable them there as well once they get in. Thanks! Martin
On 11/21/2013, 12:09 PM, Martin Jambor wrote: > Hi, > > the patch below enables IRA live-range splitting that later > facilitates shrink-wrapping also work on ppc64. The difference is > that while on x86_64 it was enough to look for single sets from a hard > register to a pseudo in the first BB, on ppc the instructions are more > complicated and can look like this (example from pr10474.c testcase): > > (insn 6 3 7 2 (parallel [ > (set (reg:CC 124) > (compare:CC (reg:DI 3 3 [ i ]) > (const_int 0 [0]))) > (set (reg/v/f:DI 123 [ i ]) > (reg:DI 3 3 [ i ])) > ]) pr10474.c:6 428 {*movdi_internal2} > (expr_list:REG_DEAD (reg:DI 3 3 [ i ]) > (nil))) > > So I changed the code that determines whether an instruction is > interesting or not to also go through a parallel instructions and be > happy with them if there is exactly one interesting SET part. > > Unfortunately, I also had to change two testcases that check this to > use long instead of int, otherwise I get SUBREG uses that make > split_live_ranges_for_shrink_wrap give up. I will try to get rid of > that limitation (and have other ideas for improvement as well) but > that is something for 4.10. It works for pointers (e.g. in pr10474.c) > and that is probably most important. > > Bootstrapped and tested on ppc64-linux ("all" languages), x86_64-linux > ("all" languages + Ada and ObjC++) and on ia64-linux (C, C++ and > Fortran). OK for trunk? > > It looks ok to me, Martin. The only problem is stage 3 start today. I don't know what to do in this situation. So let the release managers decide this. On the other hand a new bug (a missed optimization opportunity) can be created and then it could be a go. So the rules can work for you.
On Fri, Nov 22, 2013 at 10:10:26AM -0500, Vladimir Makarov wrote: > It looks ok to me, Martin. The only problem is stage 3 start today. > I don't know what to do in this situation. So let the release > managers decide this. On the other hand a new bug (a missed > optimization opportunity) can be created and then it could be a go. > So the rules can work for you. The patch has been posted before stage1 was over, so like usually, patches with new features posted before the freeze and approved shortly after the freeze (weeks, not months) can still go in. Jakub
On 11/22/13 08:15, Jakub Jelinek wrote: > On Fri, Nov 22, 2013 at 10:10:26AM -0500, Vladimir Makarov wrote: >> It looks ok to me, Martin. The only problem is stage 3 start today. >> I don't know what to do in this situation. So let the release >> managers decide this. On the other hand a new bug (a missed >> optimization opportunity) can be created and then it could be a go. >> So the rules can work for you. > > The patch has been posted before stage1 was over, so like usually, patches > with new features posted before the freeze and approved shortly after the > freeze (weeks, not months) can still go in. Agreed. In fact, I would suggest that anyone with a pending patch from prior to stage1 close that hasn't gotten feedback by midnight Tuesday ping their patch. I'd like to have a sense of everything that is outstanding sooner rather than later and wrap up any loose ends as quickly as possible. jeff
On 11/21/13 10:09, Martin Jambor wrote: > PR rtl-optimization/10474 > * ira.c (interesting_dest_for_shprep_1): New function. > (interesting_dest_for_shprep): Use interesting_dest_for_shprep_1, > also check parallels. > > testsuite/ > * gcc.dg/pr10474.c: Also test ppc64. > * gcc.dg/ira-shrinkwrap-prep-1.c: Also tes ppc64, changed all ints > to longs. > * gcc.dg/ira-shrinkwrap-prep-2.c: Likewise. I went ahead and installed this on your behalf -- just trying to get the queues flushed out. jeff
Hi, On Fri, Nov 22, 2013 at 12:36:55PM -0700, Jeff Law wrote: > On 11/21/13 10:09, Martin Jambor wrote: > > PR rtl-optimization/10474 > > * ira.c (interesting_dest_for_shprep_1): New function. > > (interesting_dest_for_shprep): Use interesting_dest_for_shprep_1, > > also check parallels. > > > >testsuite/ > > * gcc.dg/pr10474.c: Also test ppc64. > > * gcc.dg/ira-shrinkwrap-prep-1.c: Also tes ppc64, changed all ints > > to longs. > > * gcc.dg/ira-shrinkwrap-prep-2.c: Likewise. > I went ahead and installed this on your behalf -- just trying to get > the queues flushed out. Well, I specifically did not want to commit an IRA patch just before I left for the weekend... so, thanks for the confidence :-) Martin
On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote: > In fact, I would suggest that anyone with a pending patch from prior > to stage1 close that hasn't gotten feedback by midnight Tuesday ping > their patch. I'd like to have a sense of everything that is > outstanding sooner rather than later and wrap up any loose ends as > quickly as possible. Ok, doing that now for my pending patches: Masked load/store vectorization: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01268.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01437.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01550.html Elemental function support (updated version of the earlier patch): http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03197.html AddressSanitizer use-after-return instrumentation: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02070.html Use libbacktrace for libsanitizer's symbolization (will need tweaking, depending on next libsanitizer merge, whether the corresponding sanitizer_common changes are upstreamed or not, and perhaps to compile libbacktrace sources again with renamed function names and other tweaks - different allocator, only subset of files, etc.; but, there is a P1 bug for this anyway): http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02055.html Jakub
Here is the patch series that had been posted in Sep that is aimed to isolate the Android support from targets that actually don't have that support (We discussed the need of it with Jakub here http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00185.html): http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01420.html thanks, Alexander 2013/11/27 Jakub Jelinek <jakub@redhat.com>: > On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote: >> In fact, I would suggest that anyone with a pending patch from prior >> to stage1 close that hasn't gotten feedback by midnight Tuesday ping >> their patch. I'd like to have a sense of everything that is >> outstanding sooner rather than later and wrap up any loose ends as >> quickly as possible. > > Ok, doing that now for my pending patches: > > Masked load/store vectorization: > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01268.html > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01437.html > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01550.html > > Elemental function support (updated version of the earlier patch): > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03197.html > > AddressSanitizer use-after-return instrumentation: > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02070.html > > Use libbacktrace for libsanitizer's symbolization (will need tweaking, > depending on next libsanitizer merge, whether the corresponding > sanitizer_common changes are upstreamed or not, and perhaps to compile > libbacktrace sources again with renamed function names and other tweaks > - different allocator, only subset of files, etc.; but, there is a P1 > bug for this anyway): > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02055.html > > Jakub
Jakub Jelinek <jakub@redhat.com> writes: > On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote: >> In fact, I would suggest that anyone with a pending patch from prior >> to stage1 close that hasn't gotten feedback by midnight Tuesday ping >> their patch. I'd like to have a sense of everything that is >> outstanding sooner rather than later and wrap up any loose ends as >> quickly as possible. On my side, there's [c++, driver] Add -lrt on Solaris http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01488.html resubmitted as http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00412.html It's unclear if the more intrusive solution outlined in the second message (introduce libstdc++.spec) were acceptable in stage3, and I'm uncertain if I can get it ready in time. Rainer
On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote: > In fact, I would suggest that anyone with a pending patch from prior > to stage1 close that hasn't gotten feedback by midnight Tuesday ping > their patch. I'd like to have a sense of everything that is > outstanding sooner rather than later and wrap up any loose ends as > quickly as possible. I've pinged http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03447.html today. Marek
> In fact, I would suggest that anyone with a pending patch from prior to > stage1 close that hasn't gotten feedback by midnight Tuesday ping their > patch. I'd like to have a sense of everything that is outstanding > sooner rather than later and wrap up any loose ends as quickly as possible. Improve debug info for small structures (2) http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02007.html
On 11/27/13 05:30, Eric Botcazou wrote: >> In fact, I would suggest that anyone with a pending patch from prior to >> stage1 close that hasn't gotten feedback by midnight Tuesday ping their >> patch. I'd like to have a sense of everything that is outstanding >> sooner rather than later and wrap up any loose ends as quickly as possible. > > Improve debug info for small structures (2) > http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02007.html This is fine. Sorry about the delay. jeff
On 11/27/13 04:48, Rainer Orth wrote: > Jakub Jelinek <jakub@redhat.com> writes: > >> On Fri, Nov 22, 2013 at 09:36:18AM -0700, Jeff Law wrote: >>> In fact, I would suggest that anyone with a pending patch from prior >>> to stage1 close that hasn't gotten feedback by midnight Tuesday ping >>> their patch. I'd like to have a sense of everything that is >>> outstanding sooner rather than later and wrap up any loose ends as >>> quickly as possible. > > On my side, there's > > [c++, driver] Add -lrt on Solaris > http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01488.html > > resubmitted as > > http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00412.html > > It's unclear if the more intrusive solution outlined in the second > message (introduce libstdc++.spec) were acceptable in stage3, and I'm > uncertain if I can get it ready in time. Well, the short-term hack to g++spec.c along with the corresponding change to sol2.h is, OK for the trunk. As for the more invasive change, I'd let the C++ runtime guys decide if its too invasive for stage3. If you go that route, worst case is it's considered too invasive and it goes in during stage1 and you can remove the hack-ish solution from this patch. jeff
On 11/27/13 01:28, Alexander Ivchenko wrote: > Here is the patch series that had been posted in Sep that is aimed to > isolate the Android support from targets that actually don't have that > support (We discussed the need of it with Jakub here > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00185.html): > > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01420.html This patch series is fine. Just a minor typo in patch #4: +/* IFUNCs are supportted by glibc, but not by uClibc or Bionic. */ s/supportted/supported/ jeff
On 11/27/13 00:36, Jakub Jelinek wrote: >> > AddressSanitizer use-after-return instrumentation: > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02070.html > + HOST_WIDE_INT offset, sz; + sz = ASAN_RED_ZONE_SIZE; + sz = data.asan_vec[0] - prev_offset; Seems to me like the first assignment to sz is dead. Clearly something isn't right here. In fact, the whole fragment seems a bit wonky in that you set sz prior to the conditional, use it in the conditional, then set it in both arms. I'm guessing that structure is to simplify the conditional, which is fine. In fact, I would hazard a guess the dead assignment is a result of trying to clean things up in the conditional. + HOST_WIDE_INT offset, sz; + sz = ASAN_RED_ZONE_SIZE; + sz = data.asan_vec[0] - prev_offset; + if (data.asan_alignb > ASAN_RED_ZONE_SIZE + && data.asan_alignb <= 4096 + && sz + ASAN_RED_ZONE_SIZE >= data.asan_alignb) + { + sz = ((sz + ASAN_RED_ZONE_SIZE + data.asan_alignb - 1) + & ~(data.asan_alignb - HOST_WIDE_INT_1)) - sz; + } + else + sz = ASAN_RED_ZONE_SIZE; + offset + = alloc_stack_frame_space (sz, ASAN_RED_ZONE_SIZE); I'm assuming that the code you're generating to interface with the ubsan libraries is sane -- I don't know those APIs at all. I trust that if there's an issue you'll address is appropriately. With the fragment above fixed, this is OK. jeff
On 11/27/13 00:36, Jakub Jelinek wrote: > > Use libbacktrace for libsanitizer's symbolization (will need tweaking, > depending on next libsanitizer merge, whether the corresponding > sanitizer_common changes are upstreamed or not, and perhaps to compile > libbacktrace sources again with renamed function names and other tweaks > - different allocator, only subset of files, etc.; but, there is a P1 > bug for this anyway): > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02055.html Isn't libsanitizer maintained outside GCC? In which case making significant changes of this nature ought to be avoided. While I see the benefit in what you're doing, I question if we want to go down this road. Or is it the case that the build stuff in libsanitizer is ours and the only shared bits you'r hacking up are sanitizer_symbolizer_posix_libcdep.cc? jeff
On 11/27/13 00:36, Jakub Jelinek wrote: > > Elemental function support (updated version of the earlier patch): > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03197.html Richi OK's this earlier today. So it's good to go, right? I thought I saw some follow-up items that Richi agreed could be done later, right? Jeff
On Wed, Nov 27, 2013 at 01:26:54PM -0700, Jeff Law wrote: > On 11/27/13 00:36, Jakub Jelinek wrote: > > > >Elemental function support (updated version of the earlier patch): > >http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03197.html > Richi OK's this earlier today. So it's good to go, right? I > thought I saw some follow-up items that Richi agreed could be done > later, right? I've committed it already, and Richard has committed some related LTO fixes, will need to add omp clause LTO streaming now. Jakub
On Wed, Nov 27, 2013 at 01:11:59PM -0700, Jeff Law wrote: > On 11/27/13 00:36, Jakub Jelinek wrote: > > > >Use libbacktrace for libsanitizer's symbolization (will need tweaking, > >depending on next libsanitizer merge, whether the corresponding > >sanitizer_common changes are upstreamed or not, and perhaps to compile > >libbacktrace sources again with renamed function names and other tweaks > >- different allocator, only subset of files, etc.; but, there is a P1 > >bug for this anyway): > >http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02055.html > Isn't libsanitizer maintained outside GCC? In which case making > significant changes of this nature ought to be avoided. libsanitizer contains some files imported from upstream (pretty much all of *.cc and *.h) and the rest (configury/Makefiles etc.) is owned by GCC, as the LLVM buildsystem is very different. > While I see the benefit in what you're doing, I question if we want > to go down this road. > > Or is it the case that the build stuff in libsanitizer is ours and > the only shared bits you'r hacking up are > sanitizer_symbolizer_posix_libcdep.cc? The changes to the *.cc/*.h files actally have been committed to upstream, so a next merge from upstream will bring those changes automatically and we'll just need the build system etc. changes. When that happens (I think Kostya said he'll work on that), I'll update the patch accordingly. Jakub
Hi Jeff, >> On my side, there's >> >> [c++, driver] Add -lrt on Solaris >> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01488.html >> >> resubmitted as >> >> http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00412.html >> >> It's unclear if the more intrusive solution outlined in the second >> message (introduce libstdc++.spec) were acceptable in stage3, and I'm >> uncertain if I can get it ready in time. > Well, the short-term hack to g++spec.c along with the corresponding change > to sol2.h is, OK for the trunk. thanks, I've just installed it as a stopgap measure. > As for the more invasive change, I'd let the C++ runtime guys decide if its > too invasive for stage3. If you go that route, worst case is it's > considered too invasive and it goes in during stage1 and you can remove the > hack-ish solution from this patch. Right. I just remembered that something along this line will be needed for Solaris 10, too, which unlike Solaris 9 won't be removed in GCC 4.10. I'll see how far I get with a libstdc++.spec patch and than let the C++ maintainers decide what to do for 4.9. Rainer
On 11/28/13 00:17, Jakub Jelinek wrote: > On Wed, Nov 27, 2013 at 01:11:59PM -0700, Jeff Law wrote: >> On 11/27/13 00:36, Jakub Jelinek wrote: >>> >>> Use libbacktrace for libsanitizer's symbolization (will need tweaking, >>> depending on next libsanitizer merge, whether the corresponding >>> sanitizer_common changes are upstreamed or not, and perhaps to compile >>> libbacktrace sources again with renamed function names and other tweaks >>> - different allocator, only subset of files, etc.; but, there is a P1 >>> bug for this anyway): >>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02055.html >> Isn't libsanitizer maintained outside GCC? In which case making >> significant changes of this nature ought to be avoided. > > libsanitizer contains some files imported from upstream (pretty much all of > *.cc and *.h) and the rest (configury/Makefiles etc.) is owned by GCC, as > the LLVM buildsystem is very different. OK. I actually kindof came to the same conclusion while looking at other sanitizer library patches. > > The changes to the *.cc/*.h files actally have been committed to upstream, > so a next merge from upstream will bring those changes automatically and > we'll just need the build system etc. changes. When that happens (I think > Kostya said he'll work on that), I'll update the patch accordingly. OK. Go ahead and check it in then. Thanks for clarifying things, jeff
diff --git a/gcc/ira.c b/gcc/ira.c index f4fdb11..34d9649 100644 --- a/gcc/ira.c +++ b/gcc/ira.c @@ -4847,17 +4847,13 @@ find_moveable_pseudos (void) free_dominance_info (CDI_DOMINATORS); } - -/* If insn is interesting for parameter range-splitting shring-wrapping - preparation, i.e. it is a single set from a hard register to a pseudo, which - is live at CALL_DOM, return the destination. Otherwise return NULL. */ +/* If SET pattern SET is an assignment from a hard register to a pseudo which + is live at CALL_DOM (if non-NULL, otherwise this check is omitted), return + the destination. Otherwise return NULL. */ static rtx -interesting_dest_for_shprep (rtx insn, basic_block call_dom) +interesting_dest_for_shprep_1 (rtx set, basic_block call_dom) { - rtx set = single_set (insn); - if (!set) - return NULL; rtx src = SET_SRC (set); rtx dest = SET_DEST (set); if (!REG_P (src) || !HARD_REGISTER_P (src) @@ -4867,6 +4863,41 @@ interesting_dest_for_shprep (rtx insn, basic_block call_dom) return dest; } +/* If insn is interesting for parameter range-splitting shring-wrapping + preparation, i.e. it is a single set from a hard register to a pseudo, which + is live at CALL_DOM (if non-NULL, otherwise this check is omitted), or a + parallel statement with only one such statement, return the destination. + Otherwise return NULL. */ + +static rtx +interesting_dest_for_shprep (rtx insn, basic_block call_dom) +{ + if (!INSN_P (insn)) + return NULL; + rtx pat = PATTERN (insn); + if (GET_CODE (pat) == SET) + return interesting_dest_for_shprep_1 (pat, call_dom); + + if (GET_CODE (pat) != PARALLEL) + return NULL; + rtx ret = NULL; + for (int i = 0; i < XVECLEN (pat, 0); i++) + { + rtx sub = XVECEXP (pat, 0, i); + if (GET_CODE (sub) == USE || GET_CODE (sub) == CLOBBER) + continue; + if (GET_CODE (sub) != SET + || side_effects_p (sub)) + return NULL; + rtx dest = interesting_dest_for_shprep_1 (sub, call_dom); + if (dest && ret) + return NULL; + if (dest) + ret = dest; + } + return ret; +} + /* Split live ranges of pseudos that are loaded from hard registers in the first BB in a BB that dominates all non-sibling call if such a BB can be found and is not in a loop. Return true if the function has made any diff --git a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c index 4fc00b2..54d3e76 100644 --- a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c +++ b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c @@ -1,18 +1,18 @@ -/* { dg-do compile { target { x86_64-*-* && lp64 } } } */ +/* { dg-do compile { target { { x86_64-*-* && lp64 } || { powerpc*-*-* && lp64 } } } } */ /* { dg-options "-O3 -fdump-rtl-ira -fdump-rtl-pro_and_epilogue" } */ -int __attribute__((noinline, noclone)) -foo (int a) +long __attribute__((noinline, noclone)) +foo (long a) { return a + 5; } -static int g; +static long g; -int __attribute__((noinline, noclone)) -bar (int a) +long __attribute__((noinline, noclone)) +bar (long a) { - int r; + long r; if (a) { diff --git a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c index bb725e1..ed08494 100644 --- a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c +++ b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c @@ -1,18 +1,18 @@ -/* { dg-do compile { target { x86_64-*-* && lp64 } } } */ +/* { dg-do compile { target { { x86_64-*-* && lp64 } || { powerpc*-*-* && lp64 } } } } */ /* { dg-options "-O3 -fdump-rtl-ira -fdump-rtl-pro_and_epilogue" } */ -int __attribute__((noinline, noclone)) -foo (int a) +long __attribute__((noinline, noclone)) +foo (long a) { return a + 5; } -static int g; +static long g; -int __attribute__((noinline, noclone)) -bar (int a) +long __attribute__((noinline, noclone)) +bar (long a) { - int r; + long r; if (a) { diff --git a/gcc/testsuite/gcc.dg/pr10474.c b/gcc/testsuite/gcc.dg/pr10474.c index 08324d8..77ccc46 100644 --- a/gcc/testsuite/gcc.dg/pr10474.c +++ b/gcc/testsuite/gcc.dg/pr10474.c @@ -1,4 +1,4 @@ -/* { dg-do compile { target { x86_64-*-* && lp64 } } } */ +/* { dg-do compile { target { { x86_64-*-* && lp64 } || { powerpc*-*-* && lp64 } } } } */ /* { dg-options "-O3 -fdump-rtl-pro_and_epilogue" } */ void f(int *i)
Hi, the patch below enables IRA live-range splitting that later facilitates shrink-wrapping also work on ppc64. The difference is that while on x86_64 it was enough to look for single sets from a hard register to a pseudo in the first BB, on ppc the instructions are more complicated and can look like this (example from pr10474.c testcase): (insn 6 3 7 2 (parallel [ (set (reg:CC 124) (compare:CC (reg:DI 3 3 [ i ]) (const_int 0 [0]))) (set (reg/v/f:DI 123 [ i ]) (reg:DI 3 3 [ i ])) ]) pr10474.c:6 428 {*movdi_internal2} (expr_list:REG_DEAD (reg:DI 3 3 [ i ]) (nil))) So I changed the code that determines whether an instruction is interesting or not to also go through a parallel instructions and be happy with them if there is exactly one interesting SET part. Unfortunately, I also had to change two testcases that check this to use long instead of int, otherwise I get SUBREG uses that make split_live_ranges_for_shrink_wrap give up. I will try to get rid of that limitation (and have other ideas for improvement as well) but that is something for 4.10. It works for pointers (e.g. in pr10474.c) and that is probably most important. Bootstrapped and tested on ppc64-linux ("all" languages), x86_64-linux ("all" languages + Ada and ObjC++) and on ia64-linux (C, C++ and Fortran). OK for trunk? Thanks, Martin 2013-11-20 Martin Jambor <mjambor@suse.cz> PR rtl-optimization/10474 * ira.c (interesting_dest_for_shprep_1): New function. (interesting_dest_for_shprep): Use interesting_dest_for_shprep_1, also check parallels. testsuite/ * gcc.dg/pr10474.c: Also test ppc64. * gcc.dg/ira-shrinkwrap-prep-1.c: Also tes ppc64, changed all ints to longs. * gcc.dg/ira-shrinkwrap-prep-2.c: Likewise.