rjmccall added a comment. >> Has anyone actually asked LLVM whether they would accept fixed-point types >> into IR? I'm just a frontend guy, but it seems to me that there are >> advantages to directly representing these operations in a portable way even >> if there are no in-tree targets providing special support for them. And >> there are certainly in-tree targets that could provide such support if >> someone was motivated to do it. > > I haven't brought this up to llvm-dev, but the main reason for why we decided > to only implement this in clang was because we thought it would be a lot > harder pushing a new type into upstream llvm, especially since a lot of the > features can be supported on the frontend using clang's existing > infrastructure. We are open to adding fixed point types to LLVM IR in the > future though once all the frontend stuff is laid out and if the community is > willing to accept it.
Mostly I'm reluctant to add a ton of customization points to get more optimizable IR patterns from the frontend when I think it's really clear that the right thing to do is to represent these operations semantically through LLVM IR. If LLVM people don't want to add an `llvm::FixedPointType` then we should at least add portable intrinsics for them instead of target intrinsics, in which case there's still no point in customizing this in the frontend. Repository: rC Clang https://reviews.llvm.org/D50616 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
