llvm dev - Nov 2015 - Loop Load Elimination - RAR forward deps

Hi Adam,

I'm looking into your LLE pass in order to remove the RAR dependency
from GVN, and I've hit a problem that might need some more thinking.

I've modified your patch to cope with both kinds of dependencies in
the ForwardingCandidate class, but the way the pass gathers
informations only brings RAW dependencies:

    const auto *Deps = LAI.getDepChecker().getDependences();
    if (!Deps)
      return Candidates;

If I add RAR dependency checking on LoopAccessInfo, that'll break
everything else that depends on it, and if I scan the basic blocks for
RAR dependency in LLE itself, it would be moving the logic away from
its rightful place.

I'm thinking of renaming getDependencies() to something like
getStoreToLoadDeps() and add a getLoadToLoadDeps(). Does that seem
reasonable?

Or am I missing something obvious?

cheers,
--renato

Hi Renato,

Thanks for working on this.
> On Nov 3, 2015, at 2:50 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> 
> Hi Adam,
> 
> I'm looking into your LLE pass in order to remove the RAR dependency
> from GVN, and I've hit a problem that might need some more thinking.
> 
> I've modified your patch to cope with both kinds of dependencies in
> the ForwardingCandidate class, but the way the pass gathers
> informations only brings RAW dependencies:
> 
>    const auto *Deps = LAI.getDepChecker().getDependences();
>    if (!Deps)
>      return Candidates;
> 
> If I add RAR dependency checking on LoopAccessInfo, that'll break
> everything else that depends on it, and if I scan the basic blocks for
> RAR dependency in LLE itself, it would be moving the logic away from
> its rightful place.
> 
> I'm thinking of renaming getDependencies() to something like
> getStoreToLoadDeps() and add a getLoadToLoadDeps(). Does that seem
> reasonable?
I don’t think so.  I think we want getDependences to return everything: true,
output and input/RAR dependences and then have the client ignore the
uninteresting types.

We probably need a type enum in struct Dependence for true, output and
intput/RAR dependence (probably rename the current type to direction).

Would that work for you?  Let me know if you need help.  I should be on IRC all
day.

Just FYI, I am planning to push out the LLE set today unless testing uncovers
something unexpected.

Adam
> 
> Or am I missing something obvious?
> 
> cheers,
> --renato

On 3 November 2015 at 17:49, Adam Nemet <anemet at apple.com>
wrote:
> I don’t think so.  I think we want getDependences to return everything:
true, output and input/RAR dependences and then have the client ignore the
uninteresting types.
So, I agree with you in principle, and looking back now seems only
LoopDistribute is using it. It may be a good first strategy...

> We probably need a type enum in struct Dependence for true, output and
intput/RAR dependence (probably rename the current type to direction).
I've done that in LLE, but I guess we'll need one in LAI->MemDep too.

> Just FYI, I am planning to push out the LLE set today unless testing
uncovers something unexpected.
Fine by me. I'm working on top of it with no issues, so far.

cheers,
--renato