Page MenuHomePhabricator

Please use GitHub pull requests for new patches. Phabricator shutdown timeline

[BasicAA] BasicAA update for scalable quantity
Needs ReviewPublic

Authored by harviniriawan on Tue, Sep 5, 9:27 AM.

Details

Summary
  Allow vscale GEPs to be analysed in BasicAA if comparison is performed
between 2 GEPs that are equal in scalability (i.e. vscale vs vscale)

  This improves Codegen that is dependent on alias analysis
framework (e.g. SVE on AArch64)

Diff Detail

Event Timeline

harviniriawan created this revision.Tue, Sep 5, 9:27 AM
harviniriawan requested review of this revision.Tue, Sep 5, 9:27 AM
Herald added a project: Restricted Project. · View Herald TranscriptTue, Sep 5, 9:27 AM

I see cases where when we do Loop unrolling for SVE, that we move Load/Stores across iterations although they definitely not aliasing. This patch is trying to improve on that. In theory we should allow alias analysis when done between 2 GEPs that have the same scalable type, and memory location size.

This patch is the first series of patch to improve SVE loop unrolling, to get the full benefit, getSizeOrUnknown() must be updated as well (used in machinememoperand I believe).
Rudimentary prototyping suggests that doing this properly can give us a lot of uplift for SVE, especially in the LITTLE core

Matt added a subscriber: Matt.Tue, Sep 5, 1:26 PM
nikic added a comment.Wed, Sep 6, 9:46 AM

I'd suggest to split this into two parts: First add support for scalable LocationSize, and make sure code can handle it correctly, and then add support for scalable offsets to GEP decomposition later. I don't think the way you're currently doing it is what we want.

llvm/include/llvm/Analysis/MemoryLocation.h
107

precise() takes a TypeSize. You should be able to handle the isScalable() case in here only, rather than adjusting all callers to call a separate preciseScalable() method instead.

Hi Nikita,

Yeap sure I can do the adjustment on the precise(method)
Meanwhile, could you please elaborate on what way would you prefer how we handle the scalable offsets on GEP decomposition?

Harvin

nikic added a comment.Fri, Sep 8, 5:01 AM

Hi Nikita,

Yeap sure I can do the adjustment on the precise(method)
Meanwhile, could you please elaborate on what way would you prefer how we handle the scalable offsets on GEP decomposition?

I think vscale should be part of VariableGEPIndex, as we're modelling an expression of the form vscale * x.