Improvements in resource conflict detection related to slots

[martien-de-jong]

This started out by the realization that XM is a separate slot from X and M, and that the only mechanism that prevents them from occupying the same bundle is the format table.

ResourceCycle will make a quick check whether there's overlap in the slot bits, but will miss an X XM overlap.

The idea is that we can go through the complete format list and find the implications from XM to X and M (All formats containing XM don't allow X or M)

First, we have simplified the generated tables by removing the target-specific SlotInfo and SlotKind classes. That removes the need for MCFormats.h to include all generated format tables.

Trying to use the denser 'ConflictBits' in the check pointed out a problem, which is the nop slot as used by AIE2 to disambiguate the two stand-alone formats for XM, on in 48 bits and one in 64 bits. The latter one is only used for bundle padding. That nop slot only occurs in the 16 nop format and the 64 bit XM format, and hence is implied by A, B, S, X and M slots.
We added the notion of an artificial slot to be able to exclude it from the conflict bits.

Status

• The MCFormats simplification is operational.
• ConflictBits are computed and added to the SlotInfo, but aren't used properly
• Artificial slots can be specified, but aren't taken into account anywhere yet. The idea is to make a 'real slot mask' available in FormatInterface, and to exclude them from the ConflictBits computation in tablegen
• The implications from XM to X and M should be accounted for in SlotCounts. For use in ResMII, only the maximum count matters, so we could make XM also add to X and M
• Each non-artificial slot can be used as a conflict kernel when generating constrains in a solver model. ConflictBits can be used to represent the contribution to these conflicts.