llvm dev - Oct 2010 - [LLVMdev] address-units

Hello,

I am working on a target with native 16-bit units addressing.So, for a a[1]
reference a a+1 expression should be generated for an i16.

I found this issue discussed  before:
>From gohman at apple.com  Wed Apr  1 12:37:16 2009
From: gohman at apple.com (Dan Gohman)
Date: Wed, 1 Apr 2009 10:37:16 -0700
Subject: [LLVMdev] adjust address calculus for an architecture that does
	not address bytes
In-Reply-To: <57C38DA176A0A34A9B9F3CCCE33D3C4AFA7EFF5E0B at
FRPAR1CL009.coe.adi.dibcom.com>
References: <57C38DA176A0A34A9B9F3CCCE33D3C4AFA7EFF5E0A at
FRPAR1CL009.coe.adi.dibcom.com>
	<49D26D79.6080109 at xmos.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFA7EFF5E0B at
FRPAR1CL009.coe.adi.dibcom.com>
Message-ID: <A1A0F5A3-1736-4DF0-8468-103A236759FF at apple.com>

...
(8-bit) byte addressibility is a fairly widespread assumption in LLVM,
reaching beyond just GEP lowering.  Fixing this will require more
work than just adding a subclass, though it ought to be doable.

Go through the TargetData class and generalize anything that works
in terms of bytes to work in terms of address units.  I think you'll  
need
to extend the datalayout string syntax to support an address unit
size (in bits), and to add an address unit size field to the TargetData
class.  You'll also need to change APIs like getSizeInBytes to
getSizeInAddressUnits.

Then, you can change your target datalayout string to be in terms of
16-bit address units instead of 8-bit address units.

Then there are other places in LLVM which hardcode "8" constants
and "i8*" types; these can be fixed once the TargetData changes are
in place.

Dan


I would like to get the current status on this topic. Has anyone tried to
implement this yet?

thanks,

Jonas


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101013/c7750958/attachment.html>

On ons, 2010-10-13 at 11:49 +0200, ext Jonas Paulsson
wrote:
> Hello,
> 
> I am working on a target with native 16-bit units addressing.So, for a
> a[1] reference a a+1 expression should be generated for an i16.
> I would like to get the current status on this topic. Has anyone tried to
implement this yet?

Not sure if this is the same thing, but SPU has 16 byte memory accesses
only. Byte addressing is then "emulated" in target lowering of load
and
store instructions, and it works fairly well. Ofcourse, it is up to the
front end of the compiler to take this into account if efficient code is
desired :)

kalle