Yes, we have a detailed plan to implement a system similar to what you describe. We have worked on many compilers before, and about 1/3 of our company works on LLVM daily.
I think the best approach would be a purpose-built machine-level IR for optimal EVM generation, let’s call it “EIR” for Ethereum IR. We have a high level spec for what this IR would look like, and it would enable us to create an efficient backend for EVM. It would include gas cost information and low-level memory layout information.
I think it is just as important to consider building a frontend for Solidity, Vyper, or other languages in LLVM. Similar to Swift, we would probably want a high-level IR (not YUL) before handing it off to the rest of LLVM. For example, it would include accurate types, a CFG, and be in SSA form. Let’s call this one SOLIR for “Solidity IR.”
We have rapidly prototyped an IR that meets the frontend specifications we need inside Slither, an Ethereum static analyzer. It is still evolving and lacks, for instance, SSA but given a few more weeks of work it would be an acceptable IR to ease and enhance integration of Solidity, Vyper, and other languages into a modern compiler like LLVM. You can find details about it here: https://github.com/trailofbits/slither/wiki/SlithIR. You’ll note we already have working code and it correctly translates all Solidity available on Etherscan. Adding support for translating Vyper or LLL to this IR would only be a ~2-4 week process.
We have specs for our entire approach (frontend and backend) and want to begin working on it, however, we received no response after submitting a proposal to the Ethereum Foundation and, therefore, expect that our proposal for compiler development is no longer under consideration. We would still like to pursue this project because we think it’s the most important need for the Ethereum community to mature its software development process.
Let me know if you’d like to chat elsewhere. I can be reached at firstname.lastname@example.org.