rjmccall added a comment. In https://reviews.llvm.org/D50616#1203772, @lebedev.ri wrote:
> In https://reviews.llvm.org/D50616#1203751, @rjmccall wrote: > > > In https://reviews.llvm.org/D50616#1203692, @ebevhan wrote: > > > > > > > > > > > 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. > > > Even just adding one new LLVM IR instruction (well, intrinsic too, ideally) > already 'requires' you to to > then go around and make sure it is properly handled wrt all the other > instructions, optimizations, codegen. > > Adding a whole new type, i suspect, would be *much* more impactful. > And since it can already be represented via existing operations on existing > integer type, > it isn't obvious why that would be the right way forward. Very few things in LLVM actually try to exhaustively handle all operations. There are a couple of generic predicates on `Instruction` like `mayHaveSideEffects`, there's serialization/`.ll`-writing, and there's code-gen. The first two are not hard at all to implement, and it'd be quite simple to write a legalization pass in code-gen that turns all these operations into integer operations and which could easily be customized to support targets that want to do something more precise. The advantages of having real IR support include: - It's significant simpler for frontends. All of this logic in Clang will need to be reimplemented in any other frontend that wants to support fixed-point types. - It's much easier to test. The frontend needs to handle a lot of different code patterns that ultimately turn into the same small set of basic operations, like compound arithmetic and atomic operations and a million different things that are supposed to trigger implicit conversions. It's ver frustrating to write tests for these things when constants aren't readable and the generated IR for every operation is a ten-instruction sequence. - It's much easier to analyze and optimize. I'm sure some fixed-point optimizations can be done generically over the underlying integer ops, but many others would be much more difficult if not impossible — e.g. I would assume that the lowering of padded unsigned values exploits an assumption that the padding bit is zero, which a generic optimization cannot know. - All those ten-instruction sequences add up in their compile-time impact on every stage of the pipeline. I'm not saying it's an open-and-shut case, but LLVM is supposed to be an abstraction layer over more than just the concerns of code-generation, and even those concerns don't obviously point towards frontend expansion. Like I said, if this is just a hobby and we don't really care about supporting this as a feature beyond just checking a box, frontend expansion is definitely the easier approach for checking that box. But if we want a high-quality implementation of fixed-point types, we should represent them directly in LLVM IR. 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
