[Feature Req] Add "IR code" itself as a rpm architecture target

[hgkamath]

Recently, rpm got the ability to make binary install packages for micro-architectures levels -v2, -v3, -v4
Issue #2463
PR #2315

So, now its possible for a package developer/distributor to create rpm packages for various micro-architectures x86-64-v1, x86-64-v2, x86-64-v3, x86-64-v4 and so on.

Just a user here:
Penning a thought that occurred to me while typing up a comment to The F40 optimized binary proposal
https://discussion.fedoraproject.org/t/f40-change-proposal-optimized-binaries-for-the-amd64-architecture-system-wide/100413/28

[Feature Req] Add "IR code" itself as a rpm architecture target
IR code is intermediate-representation-code such as llvm-IR/llvm-bitcode/gimple .
The benefit of this feature request, if the idea is sound, is that
A single binary rpm package that installs to many architectures is big time/energy/space saver and
will improve a user/developers/sysadmin experience in package building and installation, not needing to be architecture unaware.

For those srpm packages whose compilation process can modified to allow tapping out the intermediate representation like llvmbitcode/gimple, and made to emit the IR code, which is included into the IR-code-rpm. Then, the IR-code-rpm can be installed onto a system in exactly the same way as the rpms for the regular micro-architectures.
Then, at post-install-time, a installer mechanism can be provided so that "IR-code" packages can be lowered to machine-code-binary and placed in the appropriate binary/library path.
I expect that, the time taken to lower the code from IR-code to machine-code-binary will be much lower than a regular mock/SRPM compile. Additionally, it won't require all the libraries and full compiler tool chain, only the last lowering and optimizing stage. The overhead to the install time may be bearable. Alternatively, a sysadmin, after a first installation, could later at a suitably chosen time install IR-code rpms and replace basic initial lower-level install with optimized-higher-level ones.

Furthermore, if the compiler generated intermediate-code is the same across architectures, it might also be the key to the elusive holy grail of one package for all architectures, and there-on-wards to any Linux distribution via appimage/flatpak.

caveat: one needs to be able to get the IR-code before architecture optimization stage is done at build-time, so that the architecture specific optimization can be done at post-install time by the final-code-lowering-stage. IR-code that has already been optimized for architecture is not usable for this idea as it will not be code-lower-able to any micro-architecture-level target.

Such deployable IRcode is probably something that compiler developers would make possible to get, and may need to evolve in consultation with the rpm packaging group. If this discussion collects ideas, pitfalls and challenges to overcome, perhaps the feature may materialize in a few years. Feasibility of this feature does not seem too far off now.

ps. I was going to file this as a ordinary github feature req issue. However, the issue template there instructs to first make a discussion.

[dmnks]

This sounds a lot like distributing software written in byte-compiled languages such as Python, which is already covered by the noarch target and a set of RPM macros and brp scripts to aid the packaging process. Typically, the .pyc files are shipped alongside the source code itself in the same binary package (generated by a brp script during rpmbuild), but if they're not, CPython will generate them on the fly and place wherever in the filesystem, much like what this proposal suggests with the "lower to machine code" step.

I think that's the extent to which RPM should deal with such specialized functionality. The primitives are already in place and widely used so adding support for such generic IR-code is "just" a matter of agreeing upon a mechanism on the distro level, as you suggested.