[Polly][PATCH 5/8] Allow the IslExprBuilder to build address of expressions

[Tobias Grosser]

On 11/08/2014 10:52, Johannes Doerfert wrote:
> On 08/11, Tobias Grosser wrote:
>> On 11/08/2014 09:36, Johannes Doerfert wrote:
>>> On 08/11, Tobias Grosser wrote:
>>>> On 10/08/2014 09:50, Johannes Doerfert wrote:
>>> In the future it might be applicable to more but the "types"
>>> still have to match, thus in our code generation the operand should
>>> result in a load/store (the store case is missing at the moment though).
>>> If you want me to factor it out, sure...
>>>
>>>> Also, I am surprised that create(Op) actually returns a load instruction? My
>>>> understanding is that we do not create load/stores for access expressions,
>>>> but that we only create the ptr value?
>>> I change the behaviour of createOpAccess to generate the load and the
>>> reason is pretty simple:
>>>    A isl_ast_expr which dumps like MemRef_sum[0] or MemRef_A[i] should
>>>    not result in a LLVM-Value representing &MemRef_sum[0] or
>>>    &MemRef_A[i]. What we did before for isl ast access expressions was
>>>    actually implementing the address of the access not the actual
>>>    access.
>>
>> Right. You should mention such things in your commit message. They are very
>> helpful to understand what you are doing.
>>
>> Nevertheless, you change just makes the behaviour unintuitive in a different
>> way.
>>
>> As proposed before, I would just assert if we see an isl_ast_access that
>> is not surrounded by the address_of instruction.
> How is that going to work?

We can move the code that computes the address expression into a 
subfunction getAddressOfAccess().

createOpAccess() becomes just an

// We currently do not have a need to create access expressions that
// load or store to memory. If we at some point need to do this,
// we need to a way to understand if an access is a load or a store
// access.
llvm_unreachable("Can not generate isl_op_access instructions")

>> And the address_of instruction could directly compute the address (using a
>> subfunction), without having to create a load that is later removed.
> We can do that.

And here we can just call getAddressOfAccess().

Tobias