On 07/27/2015 04:17 AM, Kyrill Tkachov wrote:
I experimented with resource.c and the roadblock I hit is that it
seems to have an assumption that it operates on hard regs (in fact
the struct it uses to describe the resources has a HARD_REG_SET for
the regs) and so it triggers various HARD_REGISTER_P asserts when I
try to use the functions there. if-conversion runs before register
allocation, so we're dealing with pseudos here.
Sigh. resource.c probably isn't going to be useful then.
My other attempt was to go over BB_A and mark the set registers in a
bitmap then go over BB_B and do a FOR_EACH_SUBRTX of the SET_SRC of
each insn. If a sub-rtx is a reg that is set in the bitmap from BB_A
we return false. This seemed to do the job and testing worked out ok.
That would require one walk over BB_A, one walk over BB_B but I don't
know how expensive FOR_EACH_SUBRTX walks are...
Would that be an acceptable solution?
I think the latter is reasonable. Ultimately we have to do a full look
at those rtxs, so it's unavoidable to some extent.
The only other possibility would be to use the DF framework. I'm not
sure if it's even initialized for the ifcvt code. If it is, then you
might be able to avoid some of the walking of the insns and instead walk
the DF structures.
<snip>
It fails when the last insn is not recognised, because
noce_try_cmove_arith can modify the last insn, but I have not seen
it cause any trouble. If it fails then back in noce_try_cmove_arith
we goto end_seq_and_fail which ends the sequence and throws it away
(and cancels if-conversion down that path), so it should be safe.
OK, I was working for the assumption that memoization ought not
fail, but it seems that was a bad assumption on my part. So
given noce_try_cmove_arith can change the last insn and make it
no-recognizable this code seems reasoanble.
So I think the only outstanding issues are:
1. Investigate moving rather than re-emitting insns.
I'll look into that, but what is the machinery by which one moves
insns?
I don't think we have any good generic machinery for this. I think
every pass that needs this capability unlinks the insn from the chain
and patches it back in at the new location.
jeff
