[llvm-commits] [llvm] r60857 - in /llvm/trunk: lib/CodeGen/SelectionDAG/DAGCombiner.cpp test/CodeGen/X86/add-with-overflow.ll

[Paul Schlie]

I don't know if the following may be related to this thread; but although
it can be helpful when attempting to implement bignum or crypto code for
example, to be able explicitly access the logical carry produced by a
preceding addition operation possibly via a symbol such as "__carry"; it
would be most useful to be able to programmatically typedef arbitrarily
long 2^N extended width integer types further optionally declared as one's
complement values; which are then correspondingly naturally represented
within llvm's tree structure (as opposed to attempting to approximate them
as classes composed of arrays of integers, and then having to extrapolate
carries most likely by restricting intermediate operation precision to
extract and propagate carries as required), and thereby alternatively allow
more efficient intermediate optimization and the back-ends to map extended
precision integer and/or one's-complement types and operations to target
machine more efficiently.

Possibly enabling something like:

typedef __oint(32) ocomp32; // one's complement 32 bit integer.

ocomp32 checksum = 0;

while (count--) {
    checksum += *dp++;    // 32 bit one's complement addition.
}
...

-- or --

typedef __sint(1024) sint1024; // signed 1024 bit integer.

sint1024 a = 23334332235324312334323453233124;

a = a + a;                    // signed 1024 bit integer addition.

As just a thought, having seen nothing short of having to resort to
target specific assembly code, or accept inefficient implementation
otherwise?

(I understand that C++0x enables the definition of extended integer
precision types, but my understanding is that they most likely need
to be statically predefined in the compiler, and does not enable the
specification of one's complement types as very useful in many crypto
and com-protocol implementations).