| Message ID | AANLkTinM-3HwJDLNo7BBRIXELRJf-I5VMOTUSbaitZzX@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 06/30/2010 06:56 AM, H.J. Lu wrote:
> This seems to work.
Please commit then. Sorry about the breakage, I guess one has to test
changes to i386.md on both targets.
Bernd
On Wed, Jun 30, 2010 at 10:50 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 06/30/2010 06:56 AM, H.J. Lu wrote: > >> This seems to work. > > Please commit then. Sorry about the breakage, I guess one has to test > changes to i386.md on both targets. I have committed it. Bootstrap continues until libjava which still fails for me running out of virtual memory (16GB ulimit): virtual memory exhausted: Cannot allocate memory make[3]: *** [gnu/javax/imageio/jpeg.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... virtual memory exhausted: Cannot allocate memory make[3]: *** [javax/swing/text.lo] Error 1 Richard. > > Bernd >
On 06/30/2010 11:48 AM, Richard Guenther wrote: > On Wed, Jun 30, 2010 at 10:50 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: >> On 06/30/2010 06:56 AM, H.J. Lu wrote: >> >>> This seems to work. >> >> Please commit then. Sorry about the breakage, I guess one has to test >> changes to i386.md on both targets. > > I have committed it. Bootstrap continues until libjava which still > fails for me running out of virtual memory (16GB ulimit): Is that new with the peephole2 patch? Bernd
On Wed, Jun 30, 2010 at 11:49 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 06/30/2010 11:48 AM, Richard Guenther wrote: >> On Wed, Jun 30, 2010 at 10:50 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: >>> On 06/30/2010 06:56 AM, H.J. Lu wrote: >>> >>>> This seems to work. >>> >>> Please commit then. Sorry about the breakage, I guess one has to test >>> changes to i386.md on both targets. >> >> I have committed it. Bootstrap continues until libjava which still >> fails for me running out of virtual memory (16GB ulimit): > > Is that new with the peephole2 patch? No. It is in fact http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722 Richard. > > Bernd >
On Wed, Jun 30, 2010 at 11:52 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Jun 30, 2010 at 11:49 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: >> On 06/30/2010 11:48 AM, Richard Guenther wrote: >>> On Wed, Jun 30, 2010 at 10:50 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: >>>> On 06/30/2010 06:56 AM, H.J. Lu wrote: >>>> >>>>> This seems to work. >>>> >>>> Please commit then. Sorry about the breakage, I guess one has to test >>>> changes to i386.md on both targets. >>> >>> I have committed it. Bootstrap continues until libjava which still >>> fails for me running out of virtual memory (16GB ulimit): >> >> Is that new with the peephole2 patch? > > No. It is in fact > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44722 We're peepholing in circles after your patch. The peephole2 dump isn't very informative - how can I see which peephole2s matched? Richard. > Richard. > >> >> Bernd >> >
On 06/30/2010 12:00 PM, Richard Guenther wrote: > We're peepholing in circles after your patch. The peephole2 > dump isn't very informative - how can I see which peephole2s > matched? Not easily. Maybe breakpoints on all the gen_peephole2_ functions; we should probably add that to the dumps. Seems to be something involving FIX insns, I suspect ;; Shorten x87->SSE reload sequences of fix_trunc?f?i_sse patterns. (define_peephole2 [(set (match_operand:MODEF 0 "register_operand" "") (match_operand:MODEF 1 "memory_operand" "")) (set (match_operand:SSEMODEI24 2 "register_operand" "") (fix:SSEMODEI24 (match_dup 0)))] "TARGET_SHORTEN_X87_SSE && peep2_reg_dead_p (2, operands[0])" [(set (match_dup 2) (fix:SSEMODEI24 (match_dup 1)))] "") and (define_peephole2 [(match_scratch:SF 2 "x") (set (match_operand:SSEMODEI24 0 "register_operand" "") (fix:SSEMODEI24 (match_operand:SF 1 "memory_operand" "")))] "TARGET_AVOID_VECTOR_DECODE && optimize_insn_for_speed_p ()" [(set (match_dup 2) (match_dup 1)) (set (match_dup 0) (fix:SSEMODEI24 (match_dup 2)))] "") are a loop. Bernd
On Wed, Jun 30, 2010 at 12:19 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 06/30/2010 12:00 PM, Richard Guenther wrote: > >> We're peepholing in circles after your patch. The peephole2 >> dump isn't very informative - how can I see which peephole2s >> matched? > > Not easily. Maybe breakpoints on all the gen_peephole2_ functions; we > should probably add that to the dumps. > > Seems to be something involving FIX insns, I suspect > > ;; Shorten x87->SSE reload sequences of fix_trunc?f?i_sse patterns. > (define_peephole2 > [(set (match_operand:MODEF 0 "register_operand" "") > (match_operand:MODEF 1 "memory_operand" "")) > (set (match_operand:SSEMODEI24 2 "register_operand" "") > (fix:SSEMODEI24 (match_dup 0)))] > "TARGET_SHORTEN_X87_SSE > && peep2_reg_dead_p (2, operands[0])" > [(set (match_dup 2) (fix:SSEMODEI24 (match_dup 1)))] > "") I suppose adding && !TARGET_AVOID_VECTOR_DECODE would fix it. Testing that. > and > > (define_peephole2 > [(match_scratch:SF 2 "x") > (set (match_operand:SSEMODEI24 0 "register_operand" "") > (fix:SSEMODEI24 (match_operand:SF 1 "memory_operand" "")))] > "TARGET_AVOID_VECTOR_DECODE && optimize_insn_for_speed_p ()" > [(set (match_dup 2) (match_dup 1)) > (set (match_dup 0) (fix:SSEMODEI24 (match_dup 2)))] > "") > > are a loop. > > > Bernd >
On 06/30/2010 12:31 PM, Richard Guenther wrote: > On Wed, Jun 30, 2010 at 12:19 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >> On 06/30/2010 12:00 PM, Richard Guenther wrote: >> >>> We're peepholing in circles after your patch. The peephole2 >>> dump isn't very informative - how can I see which peephole2s >>> matched? >> >> Not easily. Maybe breakpoints on all the gen_peephole2_ functions; we >> should probably add that to the dumps. >> >> Seems to be something involving FIX insns, I suspect >> >> ;; Shorten x87->SSE reload sequences of fix_trunc?f?i_sse patterns. >> (define_peephole2 >> [(set (match_operand:MODEF 0 "register_operand" "") >> (match_operand:MODEF 1 "memory_operand" "")) >> (set (match_operand:SSEMODEI24 2 "register_operand" "") >> (fix:SSEMODEI24 (match_dup 0)))] >> "TARGET_SHORTEN_X87_SSE >> && peep2_reg_dead_p (2, operands[0])" >> [(set (match_dup 2) (fix:SSEMODEI24 (match_dup 1)))] >> "") > > I suppose adding && !TARGET_AVOID_VECTOR_DECODE > would fix it. Testing that. I just added "0 &&" to one of the patterns, it also fixed the Fortran testcase. Also running a bootstrap... Do you want to take it from here with your version? Bernd
On Wed, Jun 30, 2010 at 12:41 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 06/30/2010 12:31 PM, Richard Guenther wrote: >> On Wed, Jun 30, 2010 at 12:19 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >>> On 06/30/2010 12:00 PM, Richard Guenther wrote: >>> >>>> We're peepholing in circles after your patch. The peephole2 >>>> dump isn't very informative - how can I see which peephole2s >>>> matched? >>> >>> Not easily. Maybe breakpoints on all the gen_peephole2_ functions; we >>> should probably add that to the dumps. >>> >>> Seems to be something involving FIX insns, I suspect >>> >>> ;; Shorten x87->SSE reload sequences of fix_trunc?f?i_sse patterns. >>> (define_peephole2 >>> [(set (match_operand:MODEF 0 "register_operand" "") >>> (match_operand:MODEF 1 "memory_operand" "")) >>> (set (match_operand:SSEMODEI24 2 "register_operand" "") >>> (fix:SSEMODEI24 (match_dup 0)))] >>> "TARGET_SHORTEN_X87_SSE >>> && peep2_reg_dead_p (2, operands[0])" >>> [(set (match_dup 2) (fix:SSEMODEI24 (match_dup 1)))] >>> "") >> >> I suppose adding && !TARGET_AVOID_VECTOR_DECODE >> would fix it. Testing that. > > I just added "0 &&" to one of the patterns, it also fixed the Fortran > testcase. Also running a bootstrap... > > Do you want to take it from here with your version? Yes. I'm through bootstrap and into testing right now. Richard. > > Bernd >
On Wed, Jun 30, 2010 at 2:48 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Jun 30, 2010 at 10:50 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: >> On 06/30/2010 06:56 AM, H.J. Lu wrote: >> >>> This seems to work. >> >> Please commit then. Sorry about the breakage, I guess one has to test >> changes to i386.md on both targets. > > I have committed it. Bootstrap continues until libjava which still > fails for me running out of virtual memory (16GB ulimit): > > virtual memory exhausted: Cannot allocate memory > make[3]: *** [gnu/javax/imageio/jpeg.lo] Error 1 > make[3]: *** Waiting for unfinished jobs.... > virtual memory exhausted: Cannot allocate memory > make[3]: *** [javax/swing/text.lo] Error 1 > I got bootstrap failure when configured with --with-cpu=atom: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44727
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index 7003f52..c450c38 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -17558,7 +17558,7 @@ ;; leal (%edx,%eax,4), %eax (define_peephole2 - [(match_scratch:SI 5 "r") + [(match_scratch:P 5 "r") (parallel [(set (match_operand 0 "register_operand" "") (ashift (match_operand 1 "register_operand" "") (match_operand 2 "const_int_operand" ""))) @@ -17587,9 +17587,12 @@ operands[1] = gen_rtx_PLUS (Pmode, base, gen_rtx_MULT (Pmode, index, GEN_INT (scale))); - if (mode != Pmode) - operands[1] = gen_rtx_SUBREG (mode, operands[1], 0); operands[5] = base; + if (mode != Pmode) + { + operands[1] = gen_rtx_SUBREG (mode, operands[1], 0); + operands[5] = gen_rtx_SUBREG (mode, operands[5], 0); + } operands[0] = dest; })