similar to: [LLVMdev] 64 bit shifts on 32 bit machines

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.

Yep, definitely. On Oct 27, 2008, at 3:56 PM, Duncan Sands wrote: > 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.

> >> 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? > > Yep, definitely. Are you sure expanding into inline code is a good idea? That could be quite a lot of code. Ciao, Duncan.

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::SHL, MVT::i64, Expand); setOperationAction(ISD::SRA, MVT::i64,

> Is i64 a legal type on your target? If so, you might need to hack the > code generator a bit; no in-tree target has a legal integer type that > doesn't support shifts. If not, I have no idea how you're getting > that error. Yes, well, i64 is a legal type, that's how it is. However, i64s are always stored in two 32-bit registers and in some cases need complicated

>> Yes, well, i64 is a legal type, that's how it is. However, i64s are >> always stored in two 32-bit registers and in some cases need complicated >> instruction patterns for easy things (such as add, sub and so on) that >> basically simulate the i64 behaviour with a sequence of i32 >> instructions. > I think you're misunderstanding what it means for a type

On Sat, Jan 7, 2012 at 10:18 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: > Hello, > > my target has libcall support for long long shifts. I already have the > following lines in my Lowering constructor: > >   setLibcallName(RTLIB::SHL_I64, "__llshl"); >   setLibcallName(RTLIB::SRL_I64, "__llshru"); >  

Hi, You're describing the exact same set of requirements for ARM - 64-bit loads and stores (LDRD, STRD) and multiplications but not shifts, adds, subtracts or anything else. ARM uses 32-bits as the largest possible type, and legalizes everything down to 32-bits. Why don't you do the same? Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu

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

Hi Eli, First of all, please I would appreciate that you try to not confuse my limited use of English with stupidity or lack or criteria in other subjects. I’m not English native, so please keep that in mind. You have been significantly helpful in the recent past so please keep on. Interestingly, you made a mention of a related but not identical issue. It is true that most (or all) processors

Hi Eli, Thanks for pointing to the CTLZ_ZERO_UNDEF “LibCall” implementation. I have not it in the version that I am currently using, so it’s nice to know that it’s implemented now. Incidentally, the CTLZ… implementation is IDENTICAL to what I am proposing for the Shifts. This is not just adding support for “out-of-tree-targets”, but giving consistency to the fact that we have perfectly defined

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'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

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

I had a similar problem with a backend for the 68HC12 family which also has no barrel shifter. Some 68HC12 CPUs support shift for just one of the 16-bit registers and only support rotation on the 2 8-bit subregs of that 16-bit register. That means the only practical solution for 32-bit shifts is to lower to a libcall but my situation for 16-bit shifts sounds similar to yours for 32-bit shifts. I

Johannes, Try a custom lowering of the 64bit shift instructions and then in the Lower[SRL|SHL|SRA] function, generate a call instruction to the function you want. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Johannes Birgmeier > Sent: Sunday, January 08, 2012 2:38 AM > To: llvmdev at cs.uiuc.edu

I forgot to mention that I used EXTRACT_ELEMENT in my backend to get the high and low parts of an SDValue. On 10 Nov 2013, at 17:50, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I had a similar problem with a backend for the 68HC12 family which also has no barrel shifter. Some 68HC12 CPUs support shift for just one of the 16-bit registers and only support rotation

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:

Hi Steve, Thanks for confirming that EXTRACT_ELEMENT is something I can use. I had seen it in the generated DAGs but was unsure whether I was "allowed" to use it, if that's the right word. I checked up on it more and indeed the mainstream targets like ARM use that node type in custom lowering code, so that should solve that. Perhaps in the future I might submit a patch for

On Sun, Jan 8, 2012 at 2:37 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: >> Is i64 a legal type on your target?  If so, you might need to hack the >> code generator a bit; no in-tree target has a legal integer type that >> doesn't support shifts.  If not, I have no idea how you're getting >> that error. > > Yes, well, i64 is a legal