[PATCH] D25172: [MSSA] Initial version of avoiding unnecessary use walks when calling getClobberingMemoryAccess

[Daniel Berlin via llvm-commits]

On Mon, Oct 3, 2016 at 9:04 PM, George Burgess IV <
george.burgess.iv at gmail.com> wrote:

> > So then isOptimized is "OldDef == Def"?
>
> "OldDef == getDefiningAccess()->getID()", yeah. Pointer equality initially
> seems a bit harder to get right, since we could delete a Def and, purely by
> chance, later make a new Def at the same address. Though, maybe I'm just
> being paranoid. :)
>

Right now we don't use the id's for anything but debugging. this would give
them sudden semantic meaning.
Not sure what is best to do here.


>
> > Oh, it's just more efficient than having a densemap based cache if you
> can make it work
>
> SGTM; thanks. Until we get an implementation for Defs, would it be better
> to put these methods on `MemoryUse`, then?
>
Yes.


>
> On Mon, Oct 3, 2016 at 8:24 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>>
>>
>> On Mon, Oct 3, 2016 at 5:09 PM, George Burgess IV <
>> george.burgess.iv at gmail.com> wrote:
>>
>>> george.burgess.iv added inline comments.
>>>
>>>
>>> > MemorySSA.cpp:2185
>>> > +  // Note: Currently, we do not store the optimized def result
>>> because we'd need
>>> > +  // a separate field, since we can't use it as the defining access.
>>> > +  if (StartingAccess->isOptimized())
>>>
>>> RE: `Note: ...`: can you bring me through why having this on a Def is
>>> would be useful?
>>
>>
>> Oh, it's just more efficient than having a densemap based cache if you
>> can make it work :)
>>
>> It's optimally efficient space wise, but  you may pay the price in
>> invalidaion time.
>>
>> Is the cache just invalidated too aggressively?
>>
>>
>>>
>> https://reviews.llvm.org/D25172
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161003/21e0eea5/attachment.html>