On Sat, Jan 11, 2014 at 2:42 PM, Bin.Cheng <amker.ch...@gmail.com> wrote: > On Wed, Dec 11, 2013 at 4:18 AM, Jeff Law <l...@redhat.com> wrote: >> On 12/10/13 00:01, bin.cheng wrote: >>> >>> Emm, some kind of. See the cost of iv candidate set consists of several >>> parts, the representation cost in cost pair; the register pressure cost >>> falls in dependence on invariant expressions, etc.. Here iv_ca_has_deps >>> checks whether new cost pair depends on other invariant expression which >>> is >>> not involved before, if so, current algorithm considers the new cost pair >>> has higher cost and just skips. In fact, the new cost pair may give us >>> lower overall cost even it introduces new dependence(similar to the case I >>> gave). That's why I used the overall cost comparison for good. >> >> OK. Thanks for the explanation. >> >> >>> >>> Is this new version patch looks good to you? I will re-test if it's ok. >> >> It does. Please do some final testing and it should be good to go. > Hi Jeff, sorry for responding the message so late, I have being looked > into something else. > I retested the patch against the trunk, the patch boostrap and > reg-test fine on x86 and x86_64, only causing new failure of one > fortran case 'aliasing_dummy_4.f90' with below command and error > message: > $ x86_64-linux-gnu-gfortran -O2 ../aliasing_dummy_4.f90 -S -o > aliasing_dummy_4.S -fdump-tree-all -fdump-tree-ivopts-details > -fdump-rtl-all-slim -fno-inline > ../aliasing_dummy_4.f90: in function ‘test_f90’: > ../aliasing_dummy_4.f90:28:0: internal compiler error ：Segmentation fault > call test_sub(s(1, 1)%a(:, :), 1000) ! Check "normal" references. > ^ > 0x87f14be crash_signal > ../../gcc/gcc/toplev.c:337 > 0x8786c8b reg_used_between_p(rtx_def const*, rtx_def const*, rtx_def const*) > ../../gcc/gcc/rtlanal.c:753 > 0x8efcb66 combine_reaching_defs > ../../gcc/gcc/ree.c:733 > 0x8efd4f4 find_and_remove_re > ../../gcc/gcc/ree.c:973 > 0x8efd798 rest_of_handle_ree > ../../gcc/gcc/ree.c:1035 > 0x8efd810 execute > ../../gcc/gcc/ree.c:1074 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See <http://gcc.gnu.org/bugs.html> for instructions. > > I reduced the case and attached ivopt dumps with/without the patch. > It seems the patch is doing right thing and choosing better > candidates, most likely it reveals an existing bug. > I am looking into this issue, in the meantime, I am wondering should I > apply the patch and file a PR for it, or apply the patch after root > causing it? > The issue happens for below dump before pass ree: 82: NOTE_INSN_BASIC_BLOCK 4 83: NOTE_INSN_DELETED 259: dx:DI=bp:DI 84: {dx:DI=dx:DI<<0x20;clobber flags:CC;} 86: r9:DI=zero_extend(r12:SI) 87: NOTE_INSN_DELETED 88: {r9:DI=r9:DI|dx:DI;clobber flags:CC;} 262: r12:DI=r9:DI 89: NOTE_INSN_DELETED 90: NOTE_INSN_DELETED 93: NOTE_INSN_DELETED 94: NOTE_INSN_DELETED ... It calls reg_used_between_p (r9, insn_262, insn_86), only the problem is def_insn (262) comes after cand_insn (86), the loop in reg_used_between_p goes bad at the end of instruction list with insn==NULL:
for (insn = NEXT_INSN (from_insn); insn != to_insn; insn = NEXT_INSN (insn))
if (NONDEBUG_INSN_P (insn)
&& (reg_overlap_mentioned_p (reg, PATTERN (insn))
|| (CALL_P (insn) && find_reg_fusage (insn, USE, reg))))
return 1;
What I don't understand is how the define instruction comes after the
use? It doesn't make sense even for a loop. Any words?
FYI, I attached the whole dump file before ree.
Thanks,
bin
--
Best Regards.
aliasing_dummy_4.f90.217r.split2
Description: Binary data
