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. define void @ test_input_index_constant_int(i32 addrspace(11)* %input, i32 addrspace(11)* %result) { entry: %input.addr = alloca i32 addrspace(11)* ; <i32 addrspace(11)**> [#uses=2] %result.addr = alloca i32 addrspace(11)* ; <i32 addrspace(11)**> [#uses=2] store i32 addrspace(11)* %input, i32 addrspace(11)** %input.addr store i32 addrspace(11)* %result, i32 addrspace(11)** %result.addr %tmp = load i32 addrspace(11)** %result.addr ; <i32 addrspace(11)*> [#uses=1] %tmp1 = load i32 addrspace(11)** %input.addr ; <i32 addrspace(11)*> [#uses=1] %arrayidx = getelementptr i32 addrspace(11)* %tmp1, i32 23 ; <i32 addrspace(11)*> [#uses=1] %tmp2 = load i32 addrspace(11)* %arrayidx ; <i32> [#uses=1] store i32 %tmp2, i32 addrspace(11)* %tmp ret void } 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. So my question is, how do I modified a immediate constant value from an SDValue struct? If that is not possible, what section of code do I need to modify to get LLVM to stop multiplying the index by the data size. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081006/d2035c64/attachment.html>
On Oct 6, 2008, at 9:03 AM, Villmow, Micah 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. > > define void @ test_input_index_constant_int(i32 addrspace(11)* > %input, i32 addrspace(11)* %result) { > entry: > %input.addr = alloca i32 addrspace(11)* ; <i32 > addrspace(11)**> [#uses=2] > %result.addr = alloca i32 addrspace(11)* ; > <i32 addrspace(11)**> [#uses=2] > store i32 addrspace(11)* %input, i32 addrspace(11)** > %input.addr > store i32 addrspace(11)* %result, i32 addrspace(11)** > %result.addr > %tmp = load i32 addrspace(11)** %result.addr ; > <i32 addrspace(11)*> [#uses=1] > %tmp1 = load i32 addrspace(11)** %input.addr ; > <i32 addrspace(11)*> [#uses=1] > %arrayidx = getelementptr i32 addrspace(11)* %tmp1, i32 > 23 ; <i32 addrspace(11)*> [#uses=1] > %tmp2 = load i32 addrspace(11)* %arrayidx ; > <i32> [#uses=1] > store i32 %tmp2, i32 addrspace(11)* %tmp > ret void > } > > 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. > > So my question is, how do I modified a immediate constant value from > an SDValue struct? If that is not possible, what section of code do > I need to modify to get LLVM to stop multiplying the index by the > data size.Hi Micah, You really don't want to change the semantics of the getelementptr instruction. Instead, you should change whatever is generating this instruction to generate the appropriate code. If you want to do an offset in terms of bytes, the standard way to do it is to bitcast your pointer to "i8*" and then do a getelementptr from that pointer, -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081006/c854569d/attachment.html>
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?> 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
-----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 mybackend.> However, it seems that the addresses being calculated is beingmultiplied 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 andthe> generated code is the value 96. However, I don't want thismultiplication to> occur and I cannot figure out how to divide the immediate by 4 whenlowering> 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
Apparently Analagous Threads
- [LLVMdev] Address calculation
- [LLVMdev] Address calculation
- [LLVMdev] Proposal: New IR instruction for casting between address spaces
- [LLVMdev] Proposal: New IR instruction for casting between address spaces
- [LLVMdev] Proposal: New IR instruction for casting between address spaces