@Mogball gave the feedback within the review that he’d prefer the selection of the fold API to be per dialect rather than per operation.
After further thought I think that’d be the better mechanism too, as it leads to less required changes within the TableGen files when migrating and no left over kEmitFold... constants/values after migration (essentially going back to the TableGen files looking the same as they did at the start).
It is also a familiar process and mechanism for those who have gone through the generated accessor migration.
The new mechanism leaves the hasFolder API of Ops as it was but instead adds a new useFoldAPI (bikeshedding welcome) field to dialects, which controls which fold API should be generated for Ops within a dialect.
The constants remain the same as in the initial RFC, that is kEmitRawAttributesFolder for the legacy API and kEmitFoldAdaptorFolder for the new one, with the exception of kEmitNoFolder no longer being required, nor their exact values being of any importance.
The migration process would then go roughly the same as it did for when the new generated accessor prefixes were implemented:
- Change fold of upstream dialects to use the
FoldAdaptor - Some time after a PSA, change the default fold API to use
FoldAdaptors - Some time after a PSA, remove the option to generate the old fold API entirely
Please tell if you have any issues or concerns with these proposed changes.