On 9/13/18 8:08 AM, Andrew Stubbs wrote: > 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? I would expect dataflow to treat the SCC save as a use of the SCC register. That's likely to cause it to be live on all paths from the entry to the SCC save.
Jeff
