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

[Paul Schlie]

Alternatively, if the thread is predominantly about how should state side-
effects of predominant interest to back-end mapping and their subsequent
optimization be allowed to be represented; I agree it would seem most
flexible to enable back-ends to specify all side-effects (inclusive of any
storage/condition-code registers etc.) which their instruction mappings
mutate and/or depend to be expressed, although not necessary within the
language's original semantic tree per se.  As although many architectures
increasingly shy away from implicit state inter-dependencies, it's not
unusual for more specialized architectures to heavily rely on implicit
state to affect subsequent instruction behaviors, and ideally would be
nice to generally allow their efficient specification/implementation.
(and thereby more flexibility allow generalized extended integer support).


Paul Schlie wrote:
> 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).
>