chandlerc wrote: So looking through this, again, these are all done initially by automation. And the simple current form of that automation preserves the order of builtins in the `.def` file, and so can only merge groups when they are precisely adjacent.
FWIW, I can add logic to my script to ignore order and instead group things specifically by feature sets and attribute sets into the largest sets I can. However, this will very greatly permute the relative order of builtins in the file and it wasn't clear this was always the right call. For example, in several places there are logical groupings that seem more important that the specific feature sets, but maximally grouping by features will destroy this and merge those. So, my preference is to keep this as is, and allow folks familiar with the specific builtins to merge groups together that make logical sense in follow-up PRs. Would that work for folks to at least get us out from using the X-macros? As to benefits, there are huge benefits to using TableGen even if we're not taking fully advantage of the grouping to remove duplication. You can see some of those in #120534 which is the PR that is motivating all of my work here here. --- I did update this PR, it's now rebased on top-of-tree and the 64-bit `.def` file is correctly removed, thanks for spotting that. And as a reminder, this is dependent on #120831 -- only the last commit should really be reviewed here. https://github.com/llvm/llvm-project/pull/121043 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
