On 13/09/18 11:01, Andrew Stubbs wrote:
The assert is caused because the def-use chains indicate that SCC
conflicts with itself. I suppose the question is why is it doing that,
but it's probably do do with that being a special register that gets
used in split2 (particularly by the addptrdi3 pattern). Although, those
patterns are careful to save SCC to one side and then restore it again
after, so I'd have thought the DF analysis would work out?
I think I may have a theory on this one now....
The addptrdi3 pattern must use two 32-bit adds with a carry in SCC, but
addptr patterns are not allowed to clobber SCC, so the splitter
carefully saves and restores the old value.
This is correct at runtime, and looks correct in RTL dumps, but it means
that there's still a single rtx REG instance holding the live SCC
register, and its still live before and after the new add instruction.
Would I be right in thinking that the dataflow analysis doesn't like this?
I think I have a work-around (by using different instructions), but is
there a correct way to do this if there weren't an alternative?
Andrew
