I just signed up to this mailing list so I don't have the original email with the proposal to reply to. I got the text forwarded to me though, and here are my thoughts on it: - The requirement that it should be easy for a pass to be oblivious to bundles isn't well defined. If this means that a pass should be able to run as if the bundles weren't present, then such a pass can easily damage the "bundling". One could think of cases, where certain instruction sequences should always stay together (idioms using larx/stcx. on PPC come to my mind). If, on the other hand, it means that an "oblivious" pass should see a bundle as if it was a single instruction, then the proposed solution would not work, but it could be a reasonable requirement regardless. Another approach would be to have a pseudo-instruction (say, "macro"), which would be associated with a sequence of instructions, which have been outlined, and which have been replaced by the "macro" instruction. The "macro" instruction would have the information about registers used and defined, and it would have a link to the actual instructions that define it. - How about having bundles that contain branch targets (other than the first instruction) from the outside of the bundle? This seems like something that has a potential for causing trouble, but I can't think of any specific scenario at the moment. - It should be possible to use bundles to enclose only some selected code sequences, as opposed to having every instruction belong to some bundle. Regards, -Krzysztof -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
Hi, On 12/07/2011 01:10 AM, Krzysztof Parzyszek wrote:> Another approach would be to have a pseudo-instruction (say, "macro"), > which would be associated with a sequence of instructions, which have > been outlined, and which have been replaced by the "macro" instruction. > The "macro" instruction would have the information about registers used > and defined, and it would have a link to the actual instructions that > define it.BTW did anyone seriously consider the Carlos' proposal? The inheritance idea has its merits as it can hide several behaviors/semantics behind the "mother" MachineInstrBundle class, as far as I've understood. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043798.html -- --Pekka
On Dec 6, 2011, at 3:10 PM, Krzysztof Parzyszek wrote:> - How about having bundles that contain branch targets (other than the > first instruction) from the outside of the bundle? This seems like something > that has a potential for causing trouble, but I can't think of any specific > scenario at the moment.I think bundles could cross branches with some care. But I don't think they will ever be able to cross CFG merge points, if that's what you're asking.> - It should be possible to use bundles to enclose only some selected code > sequences, as opposed to having every instruction belong to some bundle.Yes, I'm sure Evan's approach will support this. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111207/8a3239c5/attachment.html>
On Dec 6, 2011, at 11:24 PM, Pekka Jääskeläinen wrote:> Hi, > > On 12/07/2011 01:10 AM, Krzysztof Parzyszek wrote: >> Another approach would be to have a pseudo-instruction (say, "macro"), >> which would be associated with a sequence of instructions, which have >> been outlined, and which have been replaced by the "macro" instruction. >> The "macro" instruction would have the information about registers used >> and defined, and it would have a link to the actual instructions that >> define it. > > BTW did anyone seriously consider the Carlos' proposal? The inheritance idea > has its merits as it can hide several behaviors/semantics behind the "mother" > MachineInstrBundle class, as far as I've understood. > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043798.htmlI know Evan seriously considered this, which is why he mentioned it in the proposal. But I don't think MachineInstr can be subclassed while residing in the same MI list with non-bundled instructions. I think Evan's proposal still captures the important concepts of hiding bundled MIs within their bundle. -Andy
On Wed, Dec 07, 2011 at 10:14:22AM -0800, Andrew Trick wrote:> > On Dec 6, 2011, at 3:10 PM, Krzysztof Parzyszek wrote: > > > - How about having bundles that contain branch targets (other than the > > first instruction) from the outside of the bundle? This seems like something > > that has a potential for causing trouble, but I can't think of any specific > > scenario at the moment. > > I think bundles could cross branches with some care. But I don't think they will ever be able to cross CFG merge points, if that's what you're asking.Actually, what I was getting at was a clarification on whether the bundle may or may not cross a basic block boundary. While having a bundle that contains a branch and a target of the branch may seem desirable, a bundle that has a branch target (from outside) somewhere in the middle of it seems to be a dangerous thing. Evan's proposal didn't state any requirements or limitations regarding that. If there were no such limitations in place, any generic code that is "bundle-aware" would need to take it into consideration, possibly at the expense of complexity. -Krzysztof -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum