[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

[Duncan Sands]

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

Ciao,

Duncan.