[PATCH] D74943: [GISel][KnownBits]{NFC} Add a cache mechanism to speed compile time

Fri Feb 21 11:58:41 PST 2020

dsanders added a comment.

In D74943#1887089 <https://reviews.llvm.org/D74943#1887089>, @arsenm wrote:

> In D74943#1887080 <https://reviews.llvm.org/D74943#1887080>, @dsanders wrote:
>
> > In D74943#1887032 <https://reviews.llvm.org/D74943#1887032>, @qcolombet wrote:
> >
> > > > My long term plan for the intra/inter-pass cache is based about caching based on the register too.
> > >
> > > That seems fragile to do that generally. I agree that is less likely that a register changes, but it is not programmatically impossible. E.g., we could imagine that register numbers get recycle and then we would hit a cache entry that was not intended for a register.
> > >
> > > Bottom line, whatever caching we do, it will have to be bound to some kind of observer in my opinion.
> >
> >
> > We don't recycle vreg numbers today and I'm not aware of any plans to do so. There's also no API to delete a vreg. It's technically possible to change the type but that's potentially dangerous.
> >
> > At the moment, everyone calls createVirtualRegister() when they need one that didn't exist before and the pre-existing defs at worst become unused by some/all of their uses. A vreg def is never replaced by the def of an instruction that isn't computing (or finishing computing) the same value.
>
>
> You could swap two unrelated registers with the asme type by uisng replaceRegWith, though I don't know why you would ever do that

That's true (although you'd need a third vreg with no defs/uses to do it) but as you say there's no reason to do so.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74943/new/

https://reviews.llvm.org/D74943