[PATCH] D16960: [FIX] Associate access relations with an AccessId
Tobias Grosser via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 8 07:56:35 PST 2016
On 02/08/2016 04:55 PM, Johannes Doerfert wrote:
> jdoerfert abandoned this revision.
> jdoerfert added a comment.
>
> In http://reviews.llvm.org/D16960#346383, @grosser wrote:
>
>> I wonder what changed your mind?
>
>
> I initially thought it would be hacky to replace or add code after we call the IslExprBuilder::create, however the number of places we need to do so is very limited.
>
>> I personally was not yet convinced the patch as proposed was a step in
>
>> the right direction. My main concern was that it introduced multiple,
>
>> distinct isl_ids that all had the same "string" representation, which I
>
>> am afraid might cause confusion on the way.
>
>
> It doesn't seem to make problems and I don't think it would, but (see below).
>
>> I am currently happy with creating address-of expressions and then
>
>> introducing the relevant casts ourselves. Another option I could see is
>
>> to introduce in the IslExprBuilder a function that takes an address_of
>
>> expression as well as a MemoryAccess and encapsulates the address
>
>> creation and type casting.
>
>
> The approach we take now (avoiding the creation of accesses in the IslExprBuilder but only creating the address) seems fine to me too. I don't even see the need for your alternative approach, though I would not oppose it.
OK. If everything is fine, let's leave it like this. If there are
opportunities to remove code-duplication, we should take them.
Best,
Tobias
More information about the llvm-commits
mailing list