[llvm-commits] [llvm] r58623 - in /llvm/trunk: include/llvm/CodeGen/ValueTypes.h lib/VMCore/ValueTypes.cpp test/CodeGen/X86/i2k.ll utils/TableGen/CMakeLists.txt utils/TableGen/TGValueTypes.cpp

[Chris Lattner]

On Nov 4, 2008, at 5:15 AM, Duncan Sands wrote:

>>> Here's a crazy idea.  I hear that people are working on "libllvm",
>>> a reimplementation of libgcc.  Maybe instead the code generator
>>> could be taught to generate library functions on the fly.  For
>>> example, suppose a call to __udivsi3 is needed.  Then the code
>>> generator creates the function __udivsi3 in the assembler, with
>>> weak linkage.  Thanks to weak linkage there will be only one
>>> copy no matter how many object files it turns up in, and there
>>> is no need to link with libllvm.  Now imagine that you need a
>>> similar library function to __udivsi3, but for i1024.  Then you
>>> can have the code generators squirt out __udivsiXYZ!
>>
>> I think it would be better to make an arbitrary precision version of
>> udiv that takes a pointer to the integer in memory, and the size in
>> bits as an argument.
>
> Spoilsport :)  That said, the current design of breaking big integers
> into registers is not well adapted to huge integers.  It's a bit like
> first class aggregates in that respect.  So if someone wants to go  
> down
> the i1024 arithmetic route, they probably should start by rethinking
> the break-into-registers design.

I agree, I doubt that this will be a real priority for anyone in the  
near future.

-Chris