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.

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

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