Comments on the bundle proposal

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

Hi,

  • 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

I 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

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

This sort of thing will be codified in a bundle verifier. It will check that MIs marked "within a bundle" are sequential and start with a bundle header instruction, all within the same block. A block may contain multiple branches, so "multi-way branch" bundles could be supported.

-Andy