lenary wrote: Conventionally for a feature like this the implementation order is Assembly, then CodeGen, then ABI, because you can have CodeGen without ABI (for TU-local operations).
The reason we avoided Q was because of lack of implementations, but we realised it was worth implementing assembly to ensure we had it (you've found that discussion). If you are working on a hardware implementation of Q you would like codegen for, and have the capacity to commit to helping maintain and review the CodeGen and ABI implementation, I don't think we'd have a problem having it implemented upstream. If there's no commitment to hardware, then it's less likely to justify itself. If you don't have a hardware roadmap for Q, then my personal preference would be that you focus on increasing GlobalISel support for RISC-V for things already supported by SDag, rather than implementing codegen for Q, but this is merely my preference, and I am not in charge of you :) https://github.com/llvm/llvm-project/pull/195166 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
