On Jul 13, 2011, at 4:26 AM, Anton Lokhmotov wrote:> Hi Chris, > > We have updated the half patch for TOT. Could you review please?Sorry for the delay, some thoughts: +++ b/include/llvm/Bitcode/LLVMBitCodes.h @@ -110,10 +110,12 @@ namespace bitc { TYPE_CODE_METADATA = 16, // METADATA TYPE_CODE_X86_MMX = 17, // X86 MMX + + TYPE_CODE_HALF = 18, // IEEE HALF (16-bit fp) - TYPE_CODE_STRUCT_ANON = 18, // STRUCT_ANON: [ispacked, eltty x N] - TYPE_CODE_STRUCT_NAME = 19, // STRUCT_NAME: [strchr x N] - TYPE_CODE_STRUCT_NAMED = 20 // STRUCT_NAMED: [ispacked, eltty x N] + TYPE_CODE_STRUCT_ANON = 19, // STRUCT_ANON: [ispacked, eltty x N] + TYPE_CODE_STRUCT_NAME = 20, // STRUCT_NAME: [strchr x N] + TYPE_CODE_STRUCT_NAMED = 21 // STRUCT_NAMED: [ispacked, eltty x N] Please make TYPE_CODE_HALF be "21" at the end of the list. Bitcode id's are not allowed to ever change. +++ b/include/llvm/Type.h VectorTyID, ///< 14: SIMD 'packed' format, or other vector type + HalfTyID, ///< 16: 16-bit floating-point type The comment is wrong, it should be "15:" The rest of the patch looks like a reasonable first start, but doesn't include code generation or optimizer changes. The code generator will certainly need changes to emit global variables with half floats in them (among other things) and I would expect a variety of optimizer changes scattered in for various stuff that needs to touch half floats. -Chris
Hi Chris,> Please make TYPE_CODE_HALF be "21" at the end of the list.Done.> + HalfTyID, ///< 16: 16-bit floating-point type > > The comment is wrong, it should be "15:"Fixed.> The rest of the patch looks like a reasonable first start, but doesn't > include code generation or optimizer changes. The code generator will > certainly need changes to emit global variables with half floats in > them (among other things)I was under impression that you argued that only backends for targets supporting the half type natively should implement code generation for half (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038839.html). AFAIK, there are no such open-source backends at the moment?> and I would expect a variety of optimizer changes scattered in for various > stuff that needs to touch half floats.I am afraid we could not find such special casing even for 'double'. Constant propagation does work properly as demonstrated by an included test case. Best regards, Anton. -------------- next part -------------- A non-text attachment was scrubbed... Name: half-llvm.patch Type: application/octet-stream Size: 16365 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110729/666fbc5d/attachment.obj>
Possibly Parallel Threads
- [LLVMdev] Global variable initializer type does not match global variable type
- [LLVMdev] Global variable initializer type does not match global variable type
- [PATCH 0/2] [clang-format] Add new configurations
- [LLVMdev] Proposed: first class packed structures
- [LLVMdev] LLVM IR Type System Rewrite