[LLVMdev] alias set collapse and LICM
Daniel Berlin
dberlin at dberlin.org
Fri Jun 12 15:44:02 PDT 2015
On Fri, Jun 12, 2015 at 2:58 PM, Philip Reames
<listmail at philipreames.com> wrote:
>
>
> On 06/12/2015 02:44 PM, Daniel Berlin wrote:
>>
>> Maybe it's me :)
>> I read his suggestion as "create one set that tracks all memory
>> operations", and one set that tracks "mods" he cared about.
>> That way, he could remove the readonly call from the set of "things he
>> cared about". Which is what i read your suggestion as.
>>
>> (As an even more meta question, it's not clear to me with LICM is
>> using alias set tracker instead of memory dependence of some sort,
>> since it's really trying to discover where the memory dependences for
>> a given load/store are so it knows where it can place things. Instead,
>> it hands alias set tracker all the things in the loop and says "hey,
>> is this modded in the loop", which is, IMHO, the wrong way around :P)
>
> Rephrasing LICM's aliasing queries on top of MemorySSA might actually be
> reasonable. Doing it using the existing MDA would be a non-starter
> performance wise.
Interesting, i knew it was bad from work on GVN, i didn't realize it
was that bad.
> Where does MemorySSA stand at this point? I don't
> believe it's landed yet has it?
>
I lost a bunch of weeks due to vacation and other fires, but it should
go in in the next week or two.
> Though, the only place LICM tries to place things is the loop preheader.
> The existing aliasing and guaranteed to execute logic there is actually
> pretty powerful. It's not clear that MemorySSA is strictly better here.
I agree. I was just wondering if we couldn't solve the problem without
trying to redesign alias-set tracker, since, as i'm sure you realize,
the AST problem is inherently #loads * #stores if you want
fully-precise answers. For anything less, my experience is that you
can never come up with enough special cases. Someone always finds
reasonable cases that you are still collapsing if you don't do the
queries, and they either then want a new optimization pass that uses
the info in a different way to do the same thing, or to just add "that
one more special case" to AST (Let's call this "the basicaa problem"
:P)
Interestingly, at worse, memoryssa's data structures can give you all
the ref/mod/modref'ing instructions in a block anyway (which saves you
some amount of useless walking), even if you don't rely on memoryssa
for dependence info.
More information about the llvm-dev
mailing list