Address calculation

Project Infrastructure LLVM Dev List Archives
1

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

2

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

3

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

4

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

5

You need to fix your compiler then, it is generating the wrong LLVM IR. Generating the wrong IR is not just going to cause you codegen issues, this will severely break the optimizer and just about everything else in LLVM. This path is a non-starter,

-Chris