nhaehnle wrote: > Have you considered the case where the instructions inside the bundle have > two uses of RegB, but only one of them is tied with RegA? I think it is > almost impossible to handle that optimally given only the summarised > information that you get from the operands of the BUNDLE. It might be worth > adding a test case like that, just to check that we don't crash and still > generate well formed MIR. > > The fundamental question here is, can `processTiedPairs` really operate at > the BUNDLE level (and then fix up the instructions inside)? Or is it going to > have to operate on the individual instructions (and then fix up the summary > information on the BUNDLE)?
Yes, I thought about it. I did not find a good answer to what tied operands inside of a pre-RA bundle really mean *in the general case*. Bundles mean different things to different people. The main use of bundles outside of AMDGPU is for VLIW. In AMDGPU so far, it is used for memory clauses (which could potentially have tied operands for atomicrmw, but we only form them post-RA) and for a few niche cases like keeping S_GETPC_B64 together with its uses for PC-relative addressing. What we're working towards here is a new pre-RA use case that can be vaguely described as "decomposing a single instruction into virtual micro-ops during codegen for the purpose of avoiding combinatorial explosion in opcodes etc.". For that use case, the requirements on tied operand support will be fairly restricted, and so I'd rather make this change more conservative and restrictive and not attempt to support something that we don't actually use and don't know how to test properly. And then build on that if and when we actually know what else might be needed. https://github.com/llvm/llvm-project/pull/166212 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
