RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

Hello all, I'm preparing and testing SMS correction/improvements patch and while testing it on the SPU with the vectorizer testcases I've got an ICE in the "gcc_assert ( MAX_RECOG_OPERANDS - i)" in function copy_insn_1 in emit_rtl.c. The call traces back to the loop versionioning called in modul

Re: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

Hi, Jan, Thanks for fast response! I've tested the change you proposed and we still failed in the assert checking that the number of SCRATCHes being too large (>30) while copying the REG_NOTES of the instruction (see below) using just 9 SCRATCH registers. Thanks, Vladimir On 12/18/06, Jan Hubic

Re: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

Hi, I've rebuilt again everything from scratch with the changes to emit_copy_of_insn_after as Jan suggested (see patch below) and the ICE caused by quadratic accumulation of the counter of scratch registers is gone! Thanks, Vladimir Index: emit-rtl.c

Re: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

AIL PROTECTED]> wrote: Hi, thanks for testing. I've bootstrapped/regtested this variant of patch and comitted it as obvious. Honza 2006-12-30 Jan Hubicka <[EMAIL PROTECTED]> Vladimir Yanovsky <[EMAIL PROTECTED]> * emit-rt.c (emit_copy_of_insn_after): Fix bug c

Re: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

I've bootstrapped OK C/C++/Fortran on PPC. make check-gcc is running now Thanks, Vladimir On 1/1/07, Jan Hubicka <[EMAIL PROTECTED]> wrote: > Hi, > Sorry for possibly causing confusion. I had tested the patch on my ICE > testcase and bootstrapped for -enable-languages=C, but didn't run the > fu

Re: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

The testing of the committed patch on the PPC-linux has produced no regressions relatively to the state that was before the bootstrap break-up. The same holds for the Andrew's version of the patch. 21 testsuite failures on PPC-linux that were introduced together with the bootstrap problem has disa

A problem with the loop structure

Hi all, I will greatly appreciate any suggestions regarding the following problem I have with the loop structure. I am working on Swing Modulo Scheduling with Sony SDK for SPU (based on gcc 4.1.1). Below there are 3 observation describing the problem. Thanks a lot, Vladimir 1. The problem was u

Re: A problem with the loop structure

Hi, Thanks a lot for your help and suggestions! Below I attach some more observations. I would be grateful for any more ideas on what can be wrong here. Thanks a lot, Vladimir --- The problem happens because the num_nodes o

[RFC] propagating loop dependences from trees to RTL (for SMS)

As a follow up to http://gcc.gnu.org/ml/gcc/2005-04/msg00461.html I would like to improve SMS by passing data dependencies information computed in tree-level to rtl-level SMS. Currently data-dependency graph built for use by SMS has an edge for every two data references (i.e. it's too conserva

Re: A problem with the loop structure

Hi, The problem with the ICE after the loop versioning in SMS was caused because the header of the versioned loop was at the same time the latch of the outer loop. After the versioning the nodes of the newly created loop could not be accessed by a DFS traversal of the outer loop starting from it

Does unrolling prevents doloop optimizations?

Hello, In file loop_doloop.c function doloop_condition_get makes sure that the condition is GE or NE otherwise it prevents doloop optimizations. This caused a problem for a loop which had NE condition without unrolling and EQ if unrolling was run. Can I make doloop work after the unroller? Thank

Re: Does unrolling prevents doloop optimizations?

Thanks, To make sure I understood you correctly, does it mean that the change (below in /* */) in doloop_condition_get is safe? /* We expect a GE or NE comparison with 0 or 1. */ if (/*(GET_CODE (condition) != GE && GET_CODE (condition) != NE) ||*/ (XEXP (condition, 1) != const0_rt