search for: i_shl

I get an assert @ Instructions.cpp:1774 when Op=llvm::Instruction::Shl. Should this assert avoid shift operations? Yuri

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

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 oth...

How do you determine if a shift is signed or not? ashr = always signed? lshr = always unsigned? shl = always signed? The CmpInst has the "isSigned()" function, but it appears that every other Instruction I've looked at doesn't seem to have this. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...3 at gmail.com> wrote: > How do you determine if a shift is signed or not? > > ashr = always signed? Essentially, yes. > lshr = always unsigned? Essentially, yes. > shl = always signed? Signed left shift and unsigned left shift are both shl. http://llvm.org/docs/LangRef.html#i_shl describes the semantics of shifts. > The CmpInst has the "isSigned()" function, but it appears that every other > Instruction I've looked at doesn't seem to have this. There isn't an isSigned() function because the query doesn't really make sense. LLVM IR doesn...

...signed or not? >> >> ashr = always signed? > > Essentially, yes. > >> lshr = always unsigned? > > Essentially, yes. > >> shl = always signed? > > Signed left shift and unsigned left shift are both shl. > > http://llvm.org/docs/LangRef.html#i_shl describes the semantics of shifts. > >> The CmpInst has the "isSigned()" function, but it appears that every >> other >> Instruction I've looked at doesn't seem to have this. > > There isn't an isSigned() function because the query doesn't real...

...if x is 32 bits, but for me x >> > 32 == x). > > (A) What does LLVM assume about "shift width"? "If op2 is (statically or dynamically) negative or equal to or larger than the number of bits in op1, the result is undefined." See http://llvm.org/docs/LangRef.html#i_shl. Roughly, that means that "lshr i32 %x, 32" is allowed to return any arbitrary value. If you need consistent behavior, you should explicitly mask the shift amount in the front-end. -Eli

I'm working on a Target that only uses the 5 lsbs of the shift amount. I only have 32 bit registers, no 64 bit, so 64 bit math is emulated, LLVM doing the transformations whenever I can get it to. I think I'm seeing a case where it ultimately looks like a standard multiword shift (from e.g. Hacker's Delight) is being inline expanded that assumes at least 6 bits of the shift is

...signed or not? >> >> ashr = always signed? > > Essentially, yes. > >> lshr = always unsigned? > > Essentially, yes. > >> shl = always signed? > > Signed left shift and unsigned left shift are both shl. > > http://llvm.org/docs/LangRef.html#i_shl describes the semantics of shifts. > >> The CmpInst has the "isSigned()" function, but it appears that every >> other >> Instruction I've looked at doesn't seem to have this. > > There isn't an isSigned() function because the query doesn't real...

...igned? >> >> Essentially, yes. >> >>> lshr = always unsigned? >> >> Essentially, yes. >> >>> shl = always signed? >> >> Signed left shift and unsigned left shift are both shl. >> >> http://llvm.org/docs/LangRef.html#i_shl describes the semantics of >> shifts. >> >>> The CmpInst has the "isSigned()" function, but it appears that every >>> other >>> Instruction I've looked at doesn't seem to have this. >> >> There isn't an isSigned() function b...

...igned? >> >> Essentially, yes. >> >>> lshr = always unsigned? >> >> Essentially, yes. >> >>> shl = always signed? >> >> Signed left shift and unsigned left shift are both shl. >> >> http://llvm.org/docs/LangRef.html#i_shl describes the semantics of >> shifts. >> >>> The CmpInst has the "isSigned()" function, but it appears that every >>> other >>> Instruction I've looked at doesn't seem to have this. >> >> There isn't an isSigned() function b...

...es. >>> >>>> lshr = always unsigned? >>> >>> Essentially, yes. >>> >>>> shl = always signed? >>> >>> Signed left shift and unsigned left shift are both shl. >>> >>> http://llvm.org/docs/LangRef.html#i_shl describes the semantics of >>> shifts. >>> >>>> The CmpInst has the "isSigned()" function, but it appears that every >>>> other >>>> Instruction I've looked at doesn't seem to have this. >>> >>> There isn...

...>> >> 32 == x). >> >> (A) What does LLVM assume about "shift width"? > > "If op2 is (statically or dynamically) negative or equal to or larger > than the number of bits in op1, the result is undefined." See > http://llvm.org/docs/LangRef.html#i_shl. Roughly, that means that > "lshr i32 %x, 32" is allowed to return any arbitrary value. If you > need consistent behavior, you should explicitly mask the shift amount > in the front-end. The problem here is that it looks like LLVM is introducing an expansion that assumes 32...

...lvmdev at cs.uiuc.edu > Message-ID: <4E57F946.3030307 at rawbw.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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...