[LLVMdev] design questions

[Chris Lattner]

On Wed, 4 May 2005, Adam Megacz wrote:
> Hey, I'm curious about two of the design questions in LLVM after
> reading the language reference.  If there's preexisting material
> explaining this, just point me at it (looked and couldn't find any).

No problem. :)

>  - Why unsigned types rather than signed-only like Java/JVM?  If I
>    understand correctly, their behavior is only distinguishable in
>    overflow situations, and the availability of hardware-assisted
>    overflow detection varies quite a bit across platforms.

In this case, it's not about overflow detection.  Some operators behave 
differently on signed vs unsigned data (e.g. division, remainder, <, >, 
etc).  Over time, I would like to slowly move to a situation where LLVM 
moves the signed distinction from the type-system to the operators (e.g. 
we would only have i1/i8/i16/i32/i64, but would get SMOD vs UMOD).

>  - Why identify functions by their type signatures?  I have to assume
>    that this is meant to allow overloading, but overloading is
>    generally a higher-level concept (at the "language-aware" level).

You're right.

>    Chances are quite good that the sets of arguments to two different
>    overloads of a function would wind up mapping down to the same
>    LLVM-level types (since type information is partially lost in the
>    transition).  For example, the types for polar coordinates and
>    cartesian coordinates are both {float,float}.  So most languages
>    will need to mangle symbols anyways.

You're right.

>    Actually, having an equal-by-name (in addition to the
>    equal-by-structure array/struct type operators) type in LLVM would
>    let compilers encode the distinction.  But it might complicate
>    linking conventions.

Yup, you're absolutely right :)  This is something that exists due to 
historical reasons.  It is another minor thing that we will be moving away 
from in time.

> Thanks!  Overall I was hugely impressed.  I'd had my attention focused
> on architecture-independant code generation libraries for a while, but
> being able to specify an IR outside of the language used to manipulate
> it opens up way more possibilities.  Neat stuff.

Great! :)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/