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

Support AP integers in the code generator #1642

Closed
llvmbot opened this issue Mar 24, 2007 · 9 comments
Closed

Support AP integers in the code generator #1642

llvmbot opened this issue Mar 24, 2007 · 9 comments
Labels
bugzilla Issues migrated from bugzilla enhancement Improving things as opposed to bug fixing, e.g. new or missing feature llvm:codegen

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 24, 2007

Bugzilla Link 1270
Resolution FIXED
Resolved on Apr 22, 2009 04:35
Version trunk
OS All
Depends On llvm/llvm-bugzilla-archive#1462
Reporter LLVM Bugzilla Contributor
CC @sunfishcode

Extended Description

Currently, the various targets only handle arbitrary precision integers of
discrete byte sizes (1, 2, 4, 8 bytes). However, the LLVM IR can now handle
integer bit widths from 1 bit to 8 million bits. In cases where the integer bit
size doesn't match the discrete byte size of a "known" integer, the common code
generator will generate an assertion because the integer size doesn't map to
something the machine recognizes.

This problem needs to be fixed because:

a) it prevents codegen for programs with "funny" bit sizes.
b) it prevents bit-size optimizations from working. For example, a bit size
minimization pass might be able to determine that an i32 value really only
needs 14 bits. It would thus fit into an i16 instead of an i32. However the
pass would generate i14 which would cause the common code gen to assert.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 10, 2007

Some additional notes:

  1. The <= 64bits case should be done separately from the >64 bits case. This
    can be done in terms of the machine's native integer instructions and can
    probably be done in lib/CodeGen without affecting the targets by simply
    adding the needed ext/trunc nodes.

  2. For the > 64 bits case, a much more complicated code gen is required to
    handle multi-word arithmetic (e.g. look at APInt::KnuthDivide). With some
    help from TargetData it might be possible to write some lowering code that
    generates the complicated goop necessary, but its more likely that some
    kind of runtime support (GMP?) is needed for this.

  3. Two intrinsics need to be implemented: part_set and part_select.

@lattner
Copy link
Collaborator

lattner commented Apr 10, 2007

The code generator already has partial support for i128 as well.

Supporting arbitrary width integers should be done the same way we support arbitrary width vectors:
SDISel should lower to an MVT::Integer type, then legalize should turn these into specific supported
widths.

As usual with legalize, it can turn the operations into open-coded instructions or into libcalls. We
obviously won't be able to use the GCC runtime library for the > 64 case, but that's an implementation
detail.

-Chris

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 14, 2007

Supporting arbitrary width integers should be done the same way we support
arbitrary width vectors: SDISel should lower to an MVT::Integer type, then
legalize should turn these into specific supported widths.

Are you saying you want a new MVT::Integer type that represents an arbitrary
precision integer type? If so, where does the width of the type get stored? IIRC
MVT is just an enum.

@lattner
Copy link
Collaborator

lattner commented Apr 14, 2007

yes, that is what I'm saying. It gets stored in the operand list, and we use special opcodes, just like
vectors do with VADD etc.

@lattner
Copy link
Collaborator

lattner commented Feb 18, 2008

Dan is working on this, at least for 128-bit integers. Supporting arbitrary strange sizes is probably blocked on LegalizeDAGTypes being finished.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 18, 2008

This is basically done, except for >64 bit constants (which is what Dan
is working on). It is waiting on LegalizeTypes however. Also, there is
a maximum bitwidth of 256 bits, which could easily be increased by stealing
some more bits from extended vector types.

@sunfishcode
Copy link
Member

Support for >64 bit constants in codegen is done.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 22, 2009

This is done now that LegalizeTypes has landed.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#1462

@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:codegen
Projects
None yet
Development

No branches or pull requests

4 participants