[LLVMdev] Possible bug in getCallPreservedMask for CallingConv::Intel_OCL_BI (original) (raw)
Philip Reames listmail at philipreames.com
Thu Mar 13 10:30:31 PDT 2014
- Previous message: [LLVMdev] load bytecode from string for jiting problem
- Next message: [LLVMdev] Possible bug in getCallPreservedMask for CallingConv::Intel_OCL_BI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Not sure who owns this bit of code, so sending this to the general list.
It looks like there may be an unintentional fall through happening in the X86RegisterInfo::getCallPreservedMask function.
http://llvm.org/docs/doxygen/html/X86RegisterInfo_8cpp_source.html
case CallingConv::Intel_OCL_BI <http://llvm.org/docs/doxygen/html/namespacellvm_1_1CallingConv.html#a4f861731fc6dbfdccc05af5968d98974ad47327c131a0990283111588b89587cb>: { if (IsWin64 && HasAVX512) return CSR_Win64_Intel_OCL_BI_AVX512_RegMask; if (Is64Bit && HasAVX512) return CSR_64_Intel_OCL_BI_AVX512_RegMask; if (IsWin64 && HasAVX) return CSR_Win64_Intel_OCL_BI_AVX_RegMask; if (Is64Bit && HasAVX) return CSR_64_Intel_OCL_BI_AVX_RegMask; if (!HasAVX && !IsWin64 && Is64Bit) return CSR_64_Intel_OCL_BI_RegMask; // Missing break/return? }
It may be intentional - it falls through to the Cold calling convention and then general C convention, but it really looks suspicious.
If it is intentional, please add an explicit note about the desired fall through behaviour. I found this by inserting a new case in the switch and having tests fail. The two tests that seem to hit the fallthrough behavor are: CodeGen/X86/avx-intel-ocl.ll and CodeGen/X86/sse-intel-ocl.ll
Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140313/4dffdfa7/attachment.html>
- Previous message: [LLVMdev] load bytecode from string for jiting problem
- Next message: [LLVMdev] Possible bug in getCallPreservedMask for CallingConv::Intel_OCL_BI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]