[PATCH] Scalar/PHI code genration
Johannes Doerfert
doerfert at cs.uni-saarland.de
Tue May 12 02:11:12 PDT 2015
I'll use some standard container but I won't change it today. Thanks!
On 05/08, Tobias Grosser wrote:
> In http://reviews.llvm.org/D7513#168961, @jdoerfert wrote:
>
> > I will change the stuff according to the comments (including the spelling) and then commit it.
>
>
> OK. I commented on the last issue that could need some feedback.
>
> Tobias
>
>
> ================
> Comment at: lib/Analysis/ScopInfo.cpp:888
> @@ -895,1 +887,3 @@
> + MemAccs.back()->setNextMA(MA);
> + MA = MemAccs.back();
> }
> ----------------
> jdoerfert wrote:
> > grosser wrote:
> > > Is this correct? In case we add three memory accesses A,B,C. Would this code not first add A to the map, than add a link from A to B, and then overwrite the link to B with C, which results in us loosing the link to B entirely?
> > >
> > > I somehow feel the manually implemented linked list adds unnecessary complexity and also somehow mixes the MemoryAccess definition and
> > > the InstructionToAccess mapping. I wonder if it might not be clearer to make the InstructionToAccess Map a mapping from instructions to a
> > > vector of accesses.
> > We add A and MA is null.
> >
> > We add B and MA is now A (as it was already in the Inst2Acc map)
> > As MA is not null we link B (the last access) to A:
> > B -> A
> > and change the mapping in Inst2Acc to B:
> > Inst2Acc[AccessInst] ==> B
> >
> > This way nothing is lost and in the end it looks like:
> > Inst2Acc[AccessInst] ==> C -> B -> A
> >
> >
> > We could map it to a vector but I thought the overhead would be unproportional. If you think it is worth it I can change it again.
> >
> Alright! I got a little confused by the use of MemAccs.back() as well as the *&MA items, which works both as a pointer that is passed to setNextMA() as well as a way to update Inst2Acc.
>
> Instead of using a vector we can also use std::forward_list, which should have a cost similar to what we have today, but it makes it explicit that Inst2Acc is indeed mapping to a list of Accesses.
>
> ```
> auto NewAccess = new MemoryAccess(Access, AccessInst, this, SAI);
> MemAccs.push_back(NewAccess);
>
> if (!InstructionToAccess.count(AccessInst))
> InstructionToAccess[AccessInst] = {NewAccess};
> else
> InstructionToAccess[AccessInst].push_front(NewAccess);
> ```
>
> In addition, the small, but needed changes to lookupAccessFor() would clarify that there are indeed multiple accesses per instruction. On the other side, all the manual list-management code would not be needed and we get some proper iterators for this as well.
>
> http://reviews.llvm.org/D7513
>
> EMAIL PREFERENCES
> http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
--
Johannes Doerfert
Researcher / PhD Student
Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.31
Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065 : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150512/57ec3679/attachment.sig>
More information about the llvm-commits
mailing list