LLVM IR (but not backends) should support integer bitwidths > 64 bits

[llvmbot]

Bugzilla Link	1205
Resolution	FIXED
Resolved on	Feb 22, 2010 12:48
Version	1.0
OS	Windows XP
Attachments	The c source code.
Reporter	LLVM Bugzilla Contributor

Extended Description

The llvm-dis in TOT crashed with an example temp.c, which uses 128-bit unsigned
integers. I used the following command:

llvm-gcc -c -emit-llvm -O0 temp.c -o temp.bc
opt -instcombine temp.bc -o combine.bc
llvm-dis combine.bc -f

[llvmbot]

Wei,

128-bit integers aren't supported by LLVM yet. We are currently working on
implementing this feature. Currently you are limited to 64-bit integers. We hope
to have this fixed for certain uses (like llvm-dis) within the next week.

I'm making this an enhancement request instead of a bug.

[llvmbot]

These patches implement the first increment:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045084.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045085.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045086.html

Implement the first step towards arbitrary precision integer support in
LLVM. The APInt class provides arbitrary precision arithmetic and value
representation. This patch changes ConstantInt to use APInt as its value
representation without supporting bit widths > 64 yet. That change will
come after ConstantFolding handles bit widths > 64 bits.

[llvmbot]

A plan for the implementation of this feature goes roughly as follows:

1. Make VMCore/ConstantFolding.cpp use APInt internally instead of uint64_t.
   This is now possible because ConstantInt uses APInt.
2. Make other uses of ConstantInt in VMCore compute with APInt isntead of
   uint64_t.
3. Change ScalarEvolution, ConstantRange and other Analysis passes to use
   APInt instead of uint64_t, as necessary.
4. Change InstCombine and other transforms to use APInt instead of uint64_t,
   as necessary.
5. Remove the uint64_t interface from ConstantInt so that only APInt interface
   remains.

[llvmbot]

These patches:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045105.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045109.html

make the VMCore "clean" with respect to arbitrary precision integers. It passed
a full llvm-test suite and is memory clean (checked by valgrind).

Next up: getting BCReader/BCWriter/AsmParser/AsmWriter to work with APInt.

[llvmbot]

With this patch:

The AsmWriter can now produce arbitrary precision integer output for constant
integers:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045110.html

[llvmbot]

With these patches:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045190.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045191.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045192.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045193.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045194.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045195.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045196.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045197.html

LLVM now supports arbitrary precision integers in assembly parsing, bytecode
writing, and bytecode reading.

This concludes the "VMCore" changes (step 2) on our way to completing this PR.

[llvmbot]

With these patches:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045229.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045230.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045233.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045234.html

ConstanRange is now using APInt as its values for the range. This means that
ScalarEvolution and other passes that use ConstantRange can now handle aribtrary
precision integer ranges.

[llvmbot]

A variety of small patches have got lib/Transforms and lib/Analysis completely
transformed for APInt. With the exception in Instruct Combining, LLVM should be
able to process input that uses integers > 64 bits. This is, as yet, untested,
however.

Next up: get LLI working with > 64 bits.

[llvmbot]

With these patches:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045442.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045443.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045444.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045446.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045447.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045449.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045451.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045452.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045453.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045454.html

the LLI Interpreter is capable of executing LLVM programs that use integer types
beyond 64 bits.

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#1261 has been marked as a duplicate of this bug. ***

[llvmbot]

InstructionCombining is now fairly capable at handling odd bit widths. Sheng's
changes are all committed. Its been reviewed for completeness. There might still
be some holes, however. What we need now is lots of testing.

Leo: can you update and start driving code through instcombine that is the
result of your bitwidth minimization pass?

[llvmbot]

This work (Phase 4) has been completed.