similar to: [LLVMdev] Shifts that use only 5 LSBs.

On Tue, Dec 16, 2008 at 3:36 PM, Daniel M Gessel <gessel at apple.com> wrote: > I'm working on a Target that only uses the 5 lsbs of the shift amount. Okay, that's quite common... x86 is the same. > 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. x86 is the same. > I think I'm seeing a

On Dec 16, 2008, at 7:57 PM, Eli Friedman wrote: > On Tue, Dec 16, 2008 at 3:36 PM, Daniel M Gessel <gessel at apple.com> > wrote: >> I'm working on a Target that only uses the 5 lsbs of the shift >> amount. > > Okay, that's quite common... x86 is the same. > Thanks - yes, I'd heard rumors that x86 operates the same way. >> I only have 32

On Tue, Dec 16, 2008 at 5:20 PM, Daniel M Gessel <gessel at apple.com> wrote: > The problem here is that it looks like LLVM is introducing an expansion that > assumes 32 bit shifts use more than 5 bits of the shift value. > I created a simple test function: > u64 mebbe_shift( u64 x, int test ) > { > if( test ) > x <<= 2; > return x; > } > I compile using

I can't find the bug you refer to. Also, it doesn't have this problem in x86: it uses the shldl instruction. PPC32, interestingly enough, generates something similar, but looks like it has extra instructions to or in what's guaranteed to be 0. Reminding myself of some PPC assembler though, so I'm not 100%. Thanks, Dan On Dec 16, 2008, at 9:27 PM, Eli Friedman wrote:

On Thu, Dec 18, 2008 at 1:40 PM, Daniel M Gessel <gessel at apple.com> wrote: > I can't find the bug you refer to. Did the link not work? I'll try pasting it in again. In any case, I checked in a fix disabling the broken optimization; try updating to current SVN. http://llvm.org/bugs/show_bug.cgi?id=3225 > Also, it doesn't have this problem in x86: it uses the shldl

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

Are there existing "generic" implementations for these functions under the same license as LLVM? By generic I mean C or IR that doesn't use any particular HW intrinsics. I read up on divides in Knuth's Seminumerical book, but decided to use base-2 long division on the first go-around for simplicity. I know it's not very efficient and I'm looking for shortcuts to

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

I'm getting libcalls for 64 bit shifts; any way I can get LLVM to expand all these guys? Doesn't look like it, but I wanted to sanity check before I go any further... Thanks, Dan

On Monday 27 October 2008 19:06:41 Daniel M Gessel wrote: > I'm getting libcalls for 64 bit shifts; any way I can get LLVM to > expand all these guys? Shifts by a non-constant amount, right? Ciao, Duncan.

Hi, Here is the next iteration of the patch. The only comment not addressed is this one: > It would be better to implement a target-independent check for > overflow for the "Legal" case (like how SADDO does). Hacker's > Delight > has some hints on how to do this. It's not easy for the signed case, > but is do-able. It can be lowered to a division + a branch,

Hi Duncan, I don't know if the optimization would help us much. Our architecture performs integer shifts and subtractions at the same speed. I think the optimization is limited to the case where NVBits is a power of two. That is the case for all current value types but there's a separate thread where someone is proposing adding i20 as a native type. In your previous email you mentioned

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:

On Tue, Dec 9, 2008 at 6:11 AM, Zoltan Varga <vargaz at gmail.com> wrote: >> It would be better to implement a target-independent check for >> overflow for the "Legal" case (like how SADDO does). Hacker's > Delight >> has some hints on how to do this. It's not easy for the signed case, >> but is do-able. > > It can be lowered to a division +

I'm trying to work out LLVM code which generates something similar to the following when adding large multiword numbers stored as separate words: ADD x1 x1 ADC x2 y2 ADC x3 y3 etc, where such a three argument add like ADC on x86 (which includes a carry in the addition) is available as a machine op. The background to this is that I'm trying to implement fast multiword addition in

Hi Javier, > I don't know if the optimization would help us much. Our architecture > performs integer shifts and subtractions at the same speed. I think the > optimization is limited to the case where NVBits is a power of two. it is irrelevant whether it is a power of two or not. Anyway, since you are the only user, and this is not helpful for you, I guess we can forget it :) >

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 61b0e03..d32b1a7 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -42,7 +42,7 @@ #endif /* Will never be emitted for MSVC, GCC, Intel compilers */

Duncan, Thanks for committing a fix. I see that you fixed a bug in my patch with the HiL in the case of an SRA. The issue with a test case is that it will depend on the target to expose it. Like you noted in the check-in comment x86 doesn't expose the bug. The target I'm working on isn't public. Short of writing a new one for the purpose of a test case I don't know what else to

Hello. I need to know how can R compute AIC when I study a regression model? For example, if I use these data: growth tannin 1 12 0 2 10 1 3 8 2 4 11 3 5 6 4 6 7 5 7 2 6 8 3 7 9 3 8 and I do model <- lm (growth ~ tannin) AIC(model) R responses: 38.75990 I know the following formula to compute AIC: AIC=