[cfe-dev] An unlimited-width integer type

[Finkel, Hal J. via cfe-dev]

On 11/7/19 11:41 AM, Levi Aul via cfe-dev wrote:
Hi, I'm considering writing an LLVM backend to target an abstract machine, encoding to a bytecode ISA.

This abstract machine has integers, but not in the sense of having fixed-size machine words; rather, each abstract-machine register and memory location can losslessly hold onto a distinct (non-aliasing) unlimited bit-width value, and math/bitwise ops will operate losslessly on these values to produce new values of unlimited bit-width, without any need for overflow into neighbouring registers/memory locations.

A VM implementing this abstract machine would, of course, use some kind of bignum library to implement these semantics, with each such integer value actually being a pointer to a VM-heap-allocated bignum; or, perhaps, the VM would do load-time optimization to strength-reduce some of the bignums to regular host-CPU integer types.

But, from the perspective of a compiler targeting the abstract machine itself, the ISA just "has" registers and ops of an 'iUNLIMITED' type.

Does LLVM, and specifically the LLVM IR type system, support anything like this? If not, would it be the work of days, or of months, to make it happen?


The real question is: what do you expect LLVM to do with these integers? Do you expect LLVM to optimize operations on them? Perform constant folding? If you represent them as pointers that you happen to pass to particular functions/intrinsics representing operations on them, then getting things working will be easy. Depending on the attributes you put on the functions/intrinsics, you can even get some amount of CSE. If you want more, it will likely be more work.

 -Hal




_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191107/abb661b3/attachment.html>