rjmccall added a comment. In https://reviews.llvm.org/D50616#1203692, @ebevhan wrote:
> In https://reviews.llvm.org/D50616#1203446, @leonardchan wrote: > > > Sorry I forgot to address this also. Just to make sure I understand this > > correctly since I haven't used these before: target hooks are essentially > > for emitting target specific code for some operations right? Does this mean > > that the `EmitFixedPointConversion` function should be moved to a virtual > > method under `TargetCodeGenInfo` that can be overridden and this is what > > get's called instead during conversion? > > > Yes, the thought I had was to have a virtual function in TargetCodeGenInfo > that would be called first thing in EmitFixedPointConversion, and if it > returns non-null it uses that value instead. It's a bit unfortunate in this > instance as the only thing that doesn't work for us is the saturation, but > letting you configure *parts* of the emission is a bit too specific. > > In https://reviews.llvm.org/D50616#1203635, @rjmccall wrote: > > > If this is more than just a hobby — like if there's a backend that wants to > > do serious work with matching fixed-point operations to hardware support — > > we should just add real LLVM IR support for fixed-point types instead of > > adding a bunch of frontend customization hooks. I don't know what better > > opportunity we're expecting might come along to justify that, and I don't > > think it's some incredibly onerous task to add a new leaf to the LLVM type > > hierarchy. Honestly, LLVM programmers across the board have become far too > > accustomed to pushing things opaquely through an uncooperative IR with an > > obscure muddle of intrinsics. > > > > In the meantime, we can continue working on this code. Even if there's > > eventually real IR support for fixed-point types, this code will still be > > useful; it'll just become the core of some legalization pass in the generic > > backend. > > > It definitely is; our downstream target requires it. As far as I know there's > no real use case upstream, which is why it's likely quite hard to add any > extensions to LLVM proper. Our implementation is done through intrinsics > rather than an extension of the type system, as fixed-point numbers are > really just integers under the hood. We've always wanted to upstream our > fixed-point support (or some reasonable adaptation of it) but never gotten > the impression that it would be possible since there's no upstream user. > > A mail I sent to the mailing list a while back has more details on our > implementation, including what intrinsics we've added: > http://lists.llvm.org/pipermail/cfe-dev/2018-May/058019.html We also have an > LLVM pass that converts these intrinsics into pure IR, but it's likely that > it won't work properly with some parts of this upstream design. > > Leonard's original proposal for this work has always been Clang-centric and > never planned for implementing anything on the LLVM side, so we need to make > due with what we get, but we would prefer as small a diff from upstream as > possible. 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. 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
