This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Support for full redundancy elimination and VN of virtual operands in GVN-PRE

On Jun 29, 2004, at 9:05 PM, Diego Novillo wrote:

On Tue, 2004-06-29 at 17:36, Andreas Schwab wrote:

/tmp/cvs/gcc-test-200406290400/Build/gcc/xgcc -B/tmp/cvs/gcc-test-200406290400/Build/gcc/ -B/usr/local/ia64-suse-linux/bin/ -B/usr/local/ia64-suse-linux/lib/ -isystem /usr/local/ia64-suse-linux/include -isystem /usr/local/ia64-suse-linux/sys-include -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DTHREAD_LOCAL_ALLOC=1 -DNO_EXECUTE_PERMISSION=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I/tmp/cvs/gcc-test-200406290400/boehm-gc/include -O2 -O2 -g -fexceptions -I././targ-include -I.//libc/include -O2 -O2 -g -fexceptions -I././targ-include -I.//libc/include -c ../../../boehm-gc/os_dep.c -fPIC -DPIC -o .libs/os_dep.o
../../../boehm-gc/os_dep.c: In function `GC_print_callers':
../../../boehm-gc/os_dep.c:3968: internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1170
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:> for instructions.
make[2]: *** [os_dep.lo] Error 1

Indeed.  This is a fall out from value numbering cast operations.  This
code has an operation (long int)&sym which causes the insertion code in
PRE to try to lookup &sym in its sets.

We abort in find_or_generate_expression because find_leader returns NULL
on &sym and so f_o_g_e thinks that the expression must be complex and
it's not expecting an ADDR_EXPR.

We seem to want to distinguish gimple_min_invariants from _CST nodes
very explicitly in tree-ssa-pre.c.

Just an artifact of the way support was added (actually as a bugfix, so it was the simplest change that made it work and was reasonable, i figured i'd clean it up later).
There was only a small amount of code that tried to distinguish between them, and i was going to remove the class 'c' checks (replacing them with is_gimple_min_invariant), since they no longer appeared necessary, however, i had not had time to bootstrap and check this.
It was bubbling up on my todo list, however :)

I'm not sure why. Since
add_to_value is never called for &sym, we never set TREE_CONSTANT on it,

We used to call add_to_value for it.
In fact, I'm staring at the old code, and i know this used to happen, or else we would have had the same bug you just hit :P)

We used to have:
   if (is_gimple_min_invariant (op1))
      vn_add (op0, vn_lookup_or_add (op1));

The vn_lookup part of that only checks for class 'c'.
Thus, it would try to actually lookup a value for the &sym node, and get NULL (the first time).
It would thus create a new value and call add_to_value on it, setting the value to &sym, and the value would get marked TREE_CONSTANT.

It's possible the current ordering of the checks is what screws this up. My guess is we check for an RHS being in the '1' class nodes before we check for an RHS being is_gimple_min_invariant, and thus, we valuize the expression instead of adding it whole :)

By using is_gimple_min_invariant everywhere we expect _CST, I can compile boehm-gc without a glitch. Dan, I'm sure I'm missing something so I don't want to offer this patch as a fix. Why do we work hard at distinguishing is_gimple_min_invariant from _CST nodes?

Like i said, it was only an artifact of how support was added.

I am going to be away from Jul01 to Jul04, so if this patch is not
workable, please feel free to undo my VN changes and I'll deal with the
problem after I return.

The below patch should work fine, assuming it's tested (it's what i was going to do eventually anyway, after i fixed the current memory use on 20001226-1.c), and as a nice side effect, reduce the number of values we generate.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]