[LLVMdev] Address calculation
Micah.Villmow at amd.com
Mon Oct 6 17:20:53 PDT 2008
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>
> I am attempting to get indexing code generation working with my
> However, it seems that the addresses being calculated is being
> 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
> generated code is the value 96. However, I don't want this
> occur and I cannot figure out how to divide the immediate by 4 when
> 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.
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.
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev