Yuri
2011-Aug-26 11:46 UTC
[LLVMdev] Why BinaryOperator::Create requires same argument types for shifts?
I get an assert @ Instructions.cpp:1774 when Op=llvm::Instruction::Shl. Should this assert avoid shift operations? Yuri
Stephan Falke
2011-Aug-26 12:32 UTC
[LLVMdev] Why BinaryOperator::Create requires same argument types for shifts?
Hi Yuri, As stated in LLVM's language reference manual (http://llvm.org/docs/LangRef.html#i_shl), both arguments for a shl need to have the same type. What exactly are you trying to do? --Stephan> I get an assert @ Instructions.cpp:1774 when Op=llvm::Instruction::Shl. > Should this assert avoid shift operations? > > Yuri
Yuri
2011-Aug-26 19:51 UTC
[LLVMdev] Why BinaryOperator::Create requires same argument types for shifts?
On 08/26/2011 05:32, Stephan Falke wrote:> As stated in LLVM's language reference manual > (http://llvm.org/docs/LangRef.html#i_shl), both arguments for a shl need > to have the same type.In my case, original types were uint8 (value) and uint32 (shift) llvm lacks unsigned types which made it S1=i8 and S2=i32. It's technically nothing wrong with such combination, and code works fine until I ran debug llvm for some other reason and this assert showed up. So if I need to shift signed int8 with unsigned uint32, I have to first truncate shift to uint8, with understanding that uint8 will become int8 because llvm lacks unsignedness? I think such requirement is redundant and you should make an exception in shift operator definitions to allow for any combination of numeric arguments. It forces to create an extra trunc/expand operator without the real need. Yuri
Apparently Analagous Threads
- [LLVMdev] Why BinaryOperator::Create requires same argument types for shifts?
- [LLVMdev] Why BinaryOperator::Create requires same argument types for shifts?
- [LLVMdev] OpenCL Backend
- [LLVMdev] [RFC] New StackMap format proposal (StackMap v2)
- [LLVMdev] [RFC] New StackMap format proposal (StackMap v2)