Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
llvmbot opened this issue Feb 16, 2007 · 12 comments
Closed

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

llvmbot opened this issue Feb 16, 2007 · 12 comments
Labels
bugzilla Issues migrated from bugzilla enhancement Improving things as opposed to bug fixing, e.g. new or missing feature llvm:core

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 16, 2007

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
Copy link
Collaborator Author

llvmbot commented Feb 16, 2007

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
Copy link
Collaborator Author

llvmbot commented Feb 27, 2007

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
Copy link
Collaborator Author

llvmbot commented Feb 27, 2007

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
Copy link
Collaborator Author

llvmbot commented Feb 27, 2007

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
Copy link
Collaborator Author

llvmbot commented Feb 27, 2007

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
Copy link
Collaborator Author

llvmbot commented Feb 28, 2007

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
Copy link
Collaborator Author

llvmbot commented Mar 3, 2007

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
Copy link
Collaborator Author

llvmbot commented Mar 20, 2007

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

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 27, 2007

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
Copy link
Collaborator Author

llvmbot commented Apr 7, 2007

This work (Phase 4) has been completed.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
@Endilll Endilll added enhancement Improving things as opposed to bug fixing, e.g. new or missing feature and removed new-feature labels Aug 15, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla enhancement Improving things as opposed to bug fixing, e.g. new or missing feature llvm:core
Projects
None yet
Development

No branches or pull requests

2 participants