This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH 04/25] SPECIAL_REGNO_P


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


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