On 12/11/2018 18:54, Jeff Law wrote:
On 11/12/18 10:52 AM, Andrew Stubbs wrote:
On 12/11/2018 17:20, Segher Boessenkool wrote:
If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead?
Or actually use the register, i.e. as input to an actually needed
instruction.

They're not useless. If we want to do scalar operations in vector
registers (and we often do, on this target), then we need to write a "1"
into the EXEC (vector mask) register.
Presumably you're setting up active lanes or some such.  This may
ultimately be better modeled by ignoring the problem until much later in
the pipeline.

Shortly before assembly output you run a little LCM-like pass to find
optimal points to insert the assignment to the vector register.  It's a
lot like the mode switching stuff or zeroing the upper halves of the AVX
regsiters to avoid partial register stalls.  THe local properties are
different, but these all feel like the same class of problem.

Yes, this is one of the plans. The tricky bit is getting that to work right with while_ult.

Of course, the real reason this is still an issue is finding time for it when there's lots else to be done.

Unless we want to rewrite all scalar operations in terms of vec_merge
then there's no way to "actually use the register".
I think you need to correctly model it.  If you lie to the compiler
about what's going on, you're going to run into problems.

I might investigate putting the USE inside an UNSPEC_VOLATILE. That
would have the advantage of letting combine run again. This feels like a
future project I'd rather not have block the port submission though.
The gcn_legitimate_combined_insn code isn't really acceptable though.
You need a cleaner solution here.

Now that Segher says the combine issue is a bug, I think I'll remove gcn_legitimate_combined_insn altogether -- it's only an optimization issue, after all -- and try to find a testcase I can report as a PR.

I don't suppose I can easily reproduce it on another architecture, so it'll have to wait until GCN is committed.

It's also possible that the issue has ceased to exist since GCC 7.

If there are two instructions that both have an UNSPEC_VOLATILE, will
combine coalesce them into one in the combined pattern?
I think you can put a different constant on each.

I was thinking of it the other way around. Two instructions put together would still only want to "use" EXEC once. Of course, it would only work when the required EXEC value is the same, or in the same pseudoreg.

Andrew

Reply via email to