On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from df*.[ch]
in combine but there are a couple of problems. First of all, combine
does its own DF analysis. It does so because its usage falls under this
category (df-core.c):
c) If the pass modifies insns several times, this incremental
updating may be expensive.
Furthermore, combine's DF relies on the DF scanning to be deferred, so
the DF_REF_DEF_COUNT values would be off. Eg, calls to SET_INSN_DELETED
take place before it updates the notes for those insns. Also, combine
has a tendency to undo its changes occasionally.
I think at this stage of the release cycle, converting combine to
incremental DF is probably a no-go. However, we should keep it in mind
for the future -- while hairy I'd really like to see that happen in the
long term.
As for moving this issue forward, I think the REG_N_SETs uses in combine
are valid/legitimate, so the real question in my mind is whether or not
to turn this into a vec or leave it as an array.
I'd lean for the former -- turning it into a vec gets us bounds checking
which probably would have caught this problem earlier.
This would also need a testcase for the testsuite. Presumably with a
vec version that won't be hard to create since you should get an
out-of-bounds error on the array indexing rather waiting for a segfault.
jeff
