On Mon, Dec 10, 2018 at 02:05:57PM +0000, Andrew Stubbs wrote: > On 07/12/2018 22:41, Segher Boessenkool wrote: > >On Fri, Dec 07, 2018 at 05:57:39PM +0000, 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
