[LLVMdev] design questions

[Reid Spencer]

On Wed, 2005-05-04 at 23:27 -0700, 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).
> 
>   - 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 other words, abandoning overflow detection makes the
>     duplication of types redundant, while requiring it would be a
>     great burden on CPUs that don't have overflow exception hardware.

Yes, you're right. This has been a desired change for quite some time
now. Unfortunately, its a huge impact to nearly every part of LLVM. We
will probably do it around the 2.0 time frame when we can afford to
break bytecode compatibility and generally clean up a lot of other
things as well.
> 
>   - 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).

As with all other things in LLVM, values are partitioned by their type,
not by their name. That is, identity is determined by type (structure)
equivalence. In order to distinguish functions we must type them. A by
product of this is that we get overloading for free, but its not the
main concern.

> 
>     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.

Remember that LLVM is "low level". How a higher order language decides
to deal with ambiguity in its runtime library is up to it. LLVM just
provides the capability to express what the higher level language needs.
> 
>     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.

We've thought about this and it gets debated from time to time. I think
I'll let Chris answer it, hwoever.

> 
> 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.

Yup! Glad you like it :)

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050505/30e04e92/attachment-0001.sig>