On Mon, Dec 10, 2018 at 02:05:57PM +, Andrew Stubbs wrote:
> On 07/12/2018 22:41, Segher Boessenkool wrote:
> >On Fri, Dec 07, 2018 at 05:57:39PM +, Andrew Stubbs wrote:
> >>Since the postreload_jump pass was added I'm having trouble with the AMD
> >>GCN port.
> >
> >[ snip a lot ]
> >
> >It seems thread_jump does not notice your scc in its "nonequal" regset,
> >so it thinks every later jump is based on the same scc setting as the
> >first, which explains this behaviour. Is this true, and if so, what
> >causes it?
>
> It looks like thread_jump (or maybe mark_effect) is broken when a cjump
> also clobbers the condition register.
>
> If I remove the clobber from the machine description then all is well
> (as long as there are none of the "far" branches that clobber scc).
So it sounds like it would not work correctly for any jump insns that has
an output (or a clobber). That is exactly those jump insns that are not
allowed to need a reload, too, so that may be related.
> There are a few issues here:
>
> 1. The clobber on the first cjump is not taken into account (AFAICT).
So find out why, and fix that? :-)
> 2. The clobber on the second cjump is irrelevant, but causes the bit to
> get cleared.
>
> 3. I'm not sure I understand the logic of why mark_effect clears the
> nonequal bit for clobbers at all; surely a clobber makes something
> "non-equal" just as effectively as a set?
"nonequal" here means "*might* be different", so yeah that sounds bogus.
> Is it even possible for jump threading to work when the register is
> clobbered? (It's not obvious to me that reloading the same condition
> would be detected by this algorithm, but then I don't quite follow the
> "equals" logic, yet.)
>
> Any suggestions what an acceptable fix might be?
Debug some more? (Sorry...)
Segher
