[LLVMbugs] [Bug 950] NEW: Signless Types For LLVM

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Tue Oct 17 08:52:05 PDT 2006


           Summary: Signless Types For LLVM
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com

Despite our best attempts, the LLVM type system somehow ended up too
high-level.  No! How can it be so?  Let me tell you.

The LLVM primitive integer types maintain a distinction between signed
and unsigned, when all we really want to know is the size of the data.  This
extra information bloats the .bc files and in-memory IR with "noop" casts 
(like int -> uint) and causes there to be redundancy in the LLVM language.
This redundancy in the language currently leads to horrible missed optimization
opportunities (particular in the indvars pass), but can even miss trivial
cases (i.e. not CSE'ing  (X+4) with ((unsigned)X + 4), which produce the same
value).  Another annoying thing is that 'int 1' and 'uint 1' both need to be
written out to the .bc file, which is more duplication and takes space.

As a side note, we also have three trivial bits of ugliness:
  1. we have an "SByte" type, but none of the other signed types are prefixed
     with S.
  2. Using C names like "int" and "long" make people think that LLVM types
     vary in size like C types do, depending on the target.
  3. Using all C names leads people think our type system is the same as C's,
     which is obviously untrue, but still people think that.

You can read more about this feature in Chris Lattner's LLVM Notes, at

Since this is a fairly extensive change to LLVM, this bug will be used to track
the progress of the work as it proceeds.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

More information about the llvm-bugs mailing list