Hi All, I am writing a backend for an architecture that has only 16-bit word addressing (No byte addresses ever. All data are always 16-bit). How can I specify this in the backend? As an example, consider the following instruction: %arrayidx = getelementptr [129 x i16]* @flags, i16 0, i16 %i.043 When I generate assembler code, this now results in %i.043 being multiplied by 2 in the address calculation which result in a shift being emitted. How can I avoid this? Any help would be greatly appreciated. Thanks in advance, Jacques Van Damme. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/e06ac6e9/attachment.html>
On Tue, Mar 8, 2011 at 5:14 AM, Jacques Van Damme <Jacques.VanDamme at synopsys.com> wrote:> I am writing a backend for an architecture that has only 16-bit word > addressing (No byte addresses ever. All data are always 16-bit). > > How can I specify this in the backend?In short, you can't. Word-addressable memory is not currently supported in LLVM (or Clang, for that matter).> As an example, consider the following instruction: > > %arrayidx = getelementptr [129 x i16]* @flags, i16 0, i16 %i.043 > > When I generate assembler code, this now results in %i.043 being multiplied > by 2 in the address calculation which result in a shift being emitted. > > How can I avoid this?You'll need to modify LLVM (and Clang, if that's what you are using as your front end). If you are interested, I can send you a patch of the changes that I made to the 2.8 release for a backend that targets a 24-bit word-addressable DSP, but it is quite rough and it includes changes in which you probably aren't interested (support for non-power-of-2 integer sizes and some other bug fixes). FWIW, I'm working (albeit at a glacial pace) on improving support for word-addressable memory in Clang, with the plan of eventually working my way down to LLVM. But I expect it will be a while until it is ready for production use. -Ken
Hi Ken, Thanks for the quick reply. Since I always emit assembly code, and I own the assembler, I will look into solving the problem there. Thanks anyway, Jacques. -----Original Message----- From: kjdyck at gmail.com [mailto:kjdyck at gmail.com] On Behalf Of Ken Dyck Sent: Tuesday, March 08, 2011 7:59 PM To: Jacques Van Damme Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] backend question On Tue, Mar 8, 2011 at 5:14 AM, Jacques Van Damme <Jacques.VanDamme at synopsys.com> wrote:> I am writing a backend for an architecture that has only 16-bit word > addressing (No byte addresses ever. All data are always 16-bit). > > How can I specify this in the backend?In short, you can't. Word-addressable memory is not currently supported in LLVM (or Clang, for that matter).> As an example, consider the following instruction: > > %arrayidx = getelementptr [129 x i16]* @flags, i16 0, i16 %i.043 > > When I generate assembler code, this now results in %i.043 being multiplied > by 2 in the address calculation which result in a shift being emitted. > > How can I avoid this?You'll need to modify LLVM (and Clang, if that's what you are using as your front end). If you are interested, I can send you a patch of the changes that I made to the 2.8 release for a backend that targets a 24-bit word-addressable DSP, but it is quite rough and it includes changes in which you probably aren't interested (support for non-power-of-2 integer sizes and some other bug fixes). FWIW, I'm working (albeit at a glacial pace) on improving support for word-addressable memory in Clang, with the plan of eventually working my way down to LLVM. But I expect it will be a while until it is ready for production use. -Ken
Am 08.03.2011 um 19:59 schrieb Ken Dyck:> If you are interested, I can send you a patch of the changes that I > made to the 2.8 release for a backend that targets a 24-bit > word-addressable DSP, but it is quite rough and it includes changes in > which you probably aren't interested (support for non-power-of-2 > integer sizes and some other bug fixes).I would be interested in non-power-of-two support. I started adding the very basics for i24 in my STM8 repo but there are still a couple places that do getIntegerWidth() * 2 calculations for expansion. Do you have a public repo and/or plans to merge those features into trunk? Andreas