The AccessId is a helper class that allows to associate both, ScopArrayInfo objets as well as a specific MemoryAccess with an access relations. In general all access to the same array need the same associated isl_id. Thus, it cannot be used to identify a specific MemoryAccess but only the ScopArrayInfo object. However, When the access and the array have different types, we have to (1) correct accesses generated by the IslExprBuilder or (2) annotate the access relation with the specific MemoryAccess which allows to use the correct type in the first place. This patch implements the latter approach by annotating the access relation with an AccessId that can hold a MemoryAccess or a ScopArrayInfo object. In the IslExprBuilder we check which one is present and build the most specific access we can. This also allows to remove the alignment and type correction that was implemented using the first scheme (namely, correct code later).
Details
- Reviewers
Meinersbur grosser
Diff Detail
Event Timeline
I now think we do not need this but could just use the IslExprBuilder to build the "address of" expression always and adjust the type later [as we do now]. If somebody could give me a quick answer if that is what we want to do I'll drop this revisiion.
Hi Johannes,
I wonder what changed your mind?
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.
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.
Best,
Tobias
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.