The LLVM docs seem to indicate that integer types are considered primitive, however looking at the code I see `FirstDerivedTyID = IntegerTyID`, implying that integers are derived rather than primitive. Should the docs be updated? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130811/4b8e5e02/attachment.html>
So, I did a quick experiment with the following patch:
diff --git a/include/llvm/IR/Type.h b/include/llvm/IR/Type.h
index 1bf8789..16bd376 100644
--- a/include/llvm/IR/Type.h
+++ b/include/llvm/IR/Type.h
@@ -73,8 +73,8 @@ public:
VectorTyID, ///< 15: SIMD 'packed' format, or other vector
type
NumTypeIDs, // Must remain as last defined ID
- LastPrimitiveTyID = X86_MMXTyID,
- FirstDerivedTyID = IntegerTyID
+ LastPrimitiveTyID = IntegerTyID,
+ FirstDerivedTyID = FunctionTyID
};
private:
'ninja check-all' passes. The only users of isPrimitiveType also check
isIntegerTy.
On 12 August 2013 00:52, Keno Fischer <kfischer at csail.mit.edu> wrote:
> The LLVM docs seem to indicate that integer types are considered
> primitive, however looking at the code I see `FirstDerivedTyID >
IntegerTyID`, implying that integers are derived rather than primitive.
> Should the docs be updated?
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130812/02a575cd/attachment.html>
Originally, the distinguishing feature of "primitive" types was that they were enumerable and not parameterized on anything. Then we moved to arbitrary bit-width integers types to generalize things significantly (the right move IMO). Thus, integers were no longer technically primitive types, and their categorization in code has changed to reflect this. But that doesn't make *any sense*. The documentation for primitive types also is still written in a way that would include integers. I think we just need a new distinguishing criteria for primitive versus derived types, and (to me) one immediately presents itself. Derived types are types composed of some *other* LLVM type(s) and additional information. Primitive types are not decomposable into any other LLVM type. Thus, pointers, arrays, vectors, and structures are derived from other LLVM types, while integers are primitive types and just happen to be parameterized on a specific bitwidth. If others agree, we should update both code and documentation to consistently document this distinction. Doing so would also require auditing *all* uses of the primitive information. I suspect there may be a few other places that should be clarified besides the one Joey points out. CC-ing Chris as this is really his call. -Chandler On Sun, Aug 11, 2013 at 4:52 PM, Keno Fischer <kfischer at csail.mit.edu>wrote:> The LLVM docs seem to indicate that integer types are considered > primitive, however looking at the code I see `FirstDerivedTyID > IntegerTyID`, implying that integers are derived rather than primitive. > Should the docs be updated? > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130812/1df519e2/attachment.html>
On Aug 12, 2013, at 2:15 PM, Chandler Carruth <chandlerc at google.com> wrote:> Originally, the distinguishing feature of "primitive" types was that they were enumerable and not parameterized on anything.Right.> Then we moved to arbitrary bit-width integers types to generalize things significantly (the right move IMO).Right.> Thus, integers were no longer technically primitive types, and their categorization in code has changed to reflect this. >Right.> > But that doesn't make *any sense*. The documentation for primitive types also is still written in a way that would include integers.What purpose does the notion of "primitive" types serve anymore? Why don't we just abolish that from the lexicon and from the code? -Chris