This is an archive of the discontinued LLVM Phabricator instance.

[FIX] Associate access relations with an AccessId
AbandonedPublic

Authored by jdoerfert on Feb 7 2016, 6:15 AM.

Details

Summary
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).

Diff Detail

Event Timeline

jdoerfert updated this revision to Diff 47127.Feb 7 2016, 6:15 AM
jdoerfert retitled this revision from to [FIX] Associate access relations with an AccessId.
jdoerfert added reviewers: grosser, Meinersbur.
jdoerfert updated this object.
jdoerfert added a subscriber: Restricted Project.

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.

grosser edited edge metadata.Feb 8 2016, 7:44 AM

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

jdoerfert abandoned this revision.Feb 8 2016, 7:55 AM

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.