- Original Message -
From: "Michael Meissner"
To: "Vladimir Makarov"
Cc: "Michael Meissner" , "David Edelsohn"
, "gcc-patches" , "Peter Bergner"
, aavru...@redhat.com
Sent: Friday, April 26, 2013 7:13:55 PM
Subject: Re: RF
Note, this last patch does not bootstrap on powerpc:
/home/meissner/fsf-src/meissner-lra/gcc/lra-constraints.c: In function ‘bool
process_alt_operands(int)’:
/home/meissner/fsf-src/meissner-lra/gcc/lra-constraints.c:2045:66: error:
‘small_class_operands_num’ may be used uninitialized in this func
On Fri, Apr 26, 2013 at 07:00:37PM -0400, Vladimir Makarov wrote:
> 2013-04-26 Vladimir Makarov
>
> * lra.c (setup_operand_alternative): Ignore '?'.
> * lra-constraints.c (process_alt_operands): Print cost dump for
> alternatives. Check only moves for cycling.
>
On 13-04-26 2:04 PM, Michael Meissner wrote:
In addition to all of the failures in the 32-bit gfortrain suite, I ran one run
of the 32-bit spec 2006 fortan tests, and the following benchmarks fail:
410.bwaves 416.gamess 434.zeusmp
437.leslie3d454.calculix459.Gem
On 13-04-26 11:30 AM, Michael Meissner wrote:
Vlad, in going through the LRA test differences, some of the bswap64 tests are
failing because LRA converts the swaps for register/register converts into
store/load. For example, if gcc.target/powerpc/bswap64-4.c is compiled on
32-bit, for this funct
In addition to all of the failures in the 32-bit gfortrain suite, I ran one run
of the 32-bit spec 2006 fortan tests, and the following benchmarks fail:
410.bwaves 416.gamess 434.zeusmp
437.leslie3d454.calculix459.GemsFDTD
465.tonto 481.wrf
The foll
Vlad, in going through the LRA test differences, some of the bswap64 tests are
failing because LRA converts the swaps for register/register converts into
store/load. For example, if gcc.target/powerpc/bswap64-4.c is compiled on
32-bit, for this function:
long long swap_reg (long long a) { return
On 04/25/2013 11:29 AM, Vladimir Makarov wrote:
On 04/24/2013 03:42 PM, Michael Meissner wrote:
I'm seeing a lot of failures with these changes in make check.
I've reproduced it, Mike. I'll work on it. Thanks.
I've fixed it, Mike. It is on the branch now.
2013-04-25 Vladimir Makarov
On 04/24/2013 03:42 PM, Michael Meissner wrote:
I'm seeing a lot of failures with these changes in make check.
I've reproduced it, Mike. I'll work on it. Thanks.
I'm seeing a lot of failures with these changes in make check.
The first two that I noticed on a build that did not use --with-cpu=power7:
1) c-c++-common/dfp/call-by-value.c (and others in the directory) fails with -O0
for all targets before power7 because it can't spill SDmode. Note, in the
ea
On Tue, Apr 23, 2013 at 11:37 AM, Vladimir Makarov wrote:
> Sorry, may be I missed some other places but
> could you be more specific about the place where combining lra_in_progress
> and mode happens now for legitimate address querying.
>
> I guess I explained in my previous emails why the follo
On 04/23/2013 11:33 AM, David Edelsohn wrote:
On Tue, Apr 23, 2013 at 11:03 AM, Vladimir Makarov wrote:
LRA approach is different from reload one. First of all LRA can create
pseudos (not assigned yet to anything) and secondly LRA makes changes
incrementally opposite to reload which makes
On Tue, Apr 23, 2013 at 11:03 AM, Vladimir Makarov wrote:
> LRA approach is different from reload one. First of all LRA can create
> pseudos (not assigned yet to anything) and secondly LRA makes changes
> incrementally opposite to reload which makes all final rewriting code when
> it decides t
On 04/22/2013 09:55 PM, David Edelsohn wrote:
On Mon, Apr 22, 2013 at 8:43 PM, Vladimir Makarov wrote:
* config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove
lra_in_progress guard for addressing something bigger than word.
That will work, but I'm worried that it is t
On Mon, Apr 22, 2013 at 8:43 PM, Vladimir Makarov wrote:
> * config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove
> lra_in_progress guard for addressing something bigger than word.
That will work, but I'm worried that it is too fragile. Previously
the code uniformly retu
On 13-04-22 3:31 PM, Michael Meissner wrote:
On Mon, Apr 22, 2013 at 03:26:45PM -0400, Vladimir Makarov wrote:
On 13-04-22 12:35 AM, Alan Modra wrote:
On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:
I don't understand what this check means and what comments ??? means too.
On Mon, Apr 22, 2013 at 03:26:45PM -0400, Vladimir Makarov wrote:
> On 13-04-22 12:35 AM, Alan Modra wrote:
> >On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:
> >> I don't understand what this check means and what comments ??? means too.
> >A lo_sum mem is only valid if you know
On 13-04-22 12:35 AM, Alan Modra wrote:
On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:
I don't understand what this check means and what comments ??? means too.
A lo_sum mem is only valid if you know it won't be offset (or that
offsetting will never cross a 64k+32k boundar
On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:
> If I change the above code to
>
> if (! lra_in_progress && GET_MODE_SIZE (mode) > UNITS_PER_WORD
> && !(/* ??? Assume floating point reg based on mode? */
>TARGET_HARD_FLOAT && TARGET_FPRS && TAR
On 13-04-18 4:44 PM, Vladimir Makarov wrote:
Tomorrow I am going to look at SPEC2006 dealII crash for 32-bit mode.
LRA crashes on insn
(insn 406 575 391 22 (set (reg:TF 35 3)
(mem/u/c:TF (lo_sum:SI (reg:SI 7 7 [414])
(symbol_ref/u:SI ("*.LC10") [flags 0x82])) [85 S16
On Thu, Apr 18, 2013 at 04:44:21PM -0400, Vladimir Makarov wrote:
> LRA can fix the wrong address but secondary reload was done before
> processing addresses. It could be fixed in rs6000.c code too but it
> is complicated and I found a better (and i think more right)
> solution by moving secondar
On 04/17/2013 12:10 PM, Michael Meissner wrote:
On Wed, Apr 17, 2013 at 10:14:53AM -0400, Vladimir Makarov wrote:
Mike, thanks for the patch and all the SPEC2006 data (which are
very useful as I have no access to power machine which can be used
for benchmarking). I guess that may be some bench
On Wed, Apr 17, 2013 at 10:14:53AM -0400, Vladimir Makarov wrote:
> Mike, thanks for the patch and all the SPEC2006 data (which are
> very useful as I have no access to power machine which can be used
> for benchmarking). I guess that may be some benchmark scores are
> lower because of LRA lacks
On 13-04-16 6:56 PM, Michael Meissner wrote:
I tracked down the bug with the spec 2006 benchmark WRF using the LRA register
allocator.
At one point LRA has decided to use the CTR to hold a CCmode value:
(insn 11019 11018 11020 16 (set (reg:CC 66 ctr [4411])
(reg:CC 66 ctr [4411])) modu
I tracked down the bug with the spec 2006 benchmark WRF using the LRA register
allocator.
At one point LRA has decided to use the CTR to hold a CCmode value:
(insn 11019 11018 11020 16 (set (reg:CC 66 ctr [4411])
(reg:CC 66 ctr [4411])) module_diffusion_em.fppized.f90:4885 360
{*movcc_in
On Tue, Apr 16, 2013 at 01:03:35AM +0200, Steven Bosscher wrote:
> On Tue, Apr 16, 2013 at 12:48 AM, Michael Meissner wrote:
> > 0x1055e1bf check_rtl
> > /home/meissner/fsf-src/meissner-lra/gcc/lra.c:1999
>
> These are all cases of insns not satisfying their constraints. There
> are n
On Tue, Apr 16, 2013 at 12:48 AM, Michael Meissner wrote:
> 0x1055e1bf check_rtl
> /home/meissner/fsf-src/meissner-lra/gcc/lra.c:1999
These are all cases of insns not satisfying their constraints. There
are no PRs for this, and there are no test suite failures of this kind
in the logs
I built the spec 2006 suite with/without Vlad's patches for enabling using the
LRA register allocator for the powerpc. Because of the bug with the count
register that was in the version I checked out, I have built things with the
-fno-branch-count-reg option.
I created a branch off of subversion
On Fri, Apr 12, 2013 at 12:57 PM, Vladimir Makarov wrote:
> After thorough investigation I found that this code is still ok. The
> explanations are in the comment. Here is the modified version of the code
> taking you proposals into account
>
> @@ -5701,19 +5705,31 @@ legitimate_lo_sum_address_
On 13-04-11 5:04 PM, Vladimir Makarov wrote:
On 04/11/2013 02:32 PM, David Edelsohn wrote:
On Thu, Apr 11, 2013 at 1:30 PM, Vladimir Makarov
wrote:
Here is a patch to enable LRA for rs6000. The patch includes
code changes
in rs6000 machine-dependent parts and in LRA parts.
I've added
On 04/11/2013 02:32 PM, David Edelsohn wrote:
On Thu, Apr 11, 2013 at 1:30 PM, Vladimir Makarov wrote:
Here is a patch to enable LRA for rs6000. The patch includes code changes
in rs6000 machine-dependent parts and in LRA parts.
I've added a new switch -mlra for rs6000 to make debugging
On Thu, Apr 11, 2013 at 1:30 PM, Vladimir Makarov wrote:
> Here is a patch to enable LRA for rs6000. The patch includes code changes
> in rs6000 machine-dependent parts and in LRA parts.
>
> I've added a new switch -mlra for rs6000 to make debugging LRA for rs6000
> easier but not documented
32 matches
Mail list logo
