[LLVMdev] Address calculation

Villmow, Micah Micah.Villmow at amd.com
Mon Oct 6 17:20:53 PDT 2008


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Eli Friedman
Sent: Monday, October 06, 2008 4:41 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Address calculation

On Mon, Oct 6, 2008 at 9:03 AM, Villmow, Micah <Micah.Villmow at amd.com>
wrote:
> I am attempting to get indexing code generation working with my
backend.
> However, it seems that the addresses being calculated is being
multiplied by
> the width of the data type.

That's how most normal architectures/address spaces work.  Is there
something unusual about address space 11 in your architecture?

With the backend that I'm targeting, various address spaces have
different alignment constraints. In this specific case, the number being
passed in as the offset to the pointer needs to be interpreted as the
nth element, not the nth byte. There is an underlying hw specific
compiler that does the exact address calculations, so I don't want LLVM
to make these addressing assumptions. 

> The value 23 in the getelementptr is being multiplied by 4 bytes and
the
> generated code is the value 96. However, I don't want this
multiplication to
> occur and I cannot figure out how to divide the immediate by 4 when
lowering
> the Add instruction that is linked to a  load/store operation.

CodeGen doesn't have a gep instruction, so it has to convert the
implied arithmetic into explicit arithmetic.  Is your address space 11
byte addressable?  If it isn't, you have a  very unusual case; you'll
have to hack SelectionDAGBuild.cpp to get the lowering right, and I
think some IL-level transformations assume byte addressing.  If it is,
you really want to just fold the addition into the load; it's not
trivial to match, but it shouldn't be too hard.
-Eli

Nope, this particular address space is not byte addressable, but other
address spaces in the hardware are, which is why I don't want LLVM to
make assumptions on the address calculations.

Micah

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev






More information about the llvm-dev mailing list