[llvm-dev] VModuleKey K not valid here

[Lang Hames via llvm-dev]

Hi Dibyendu,

My point was that suppose whether I added the module or not in the way
> you suggest, I still need to know which value of they VModuleKey is
> 'invalid'. In the example assume that CODLayer.addModule() is never
> called sometimes. So how do you know whether to call removeModule()?


That's definitely up to the client to track. E.g. if you want to make
removal generic.

enum class RemoveFrom { None, OptimizeLayer, CODLayer };

struct ModuleInfo {
  VModuleKey Key;
  RemoveFrom ToRemove;
};

When adding to the CODLayer:

  ModuleInfo MInfo;
  MInfo.Key = ES.allocateVModule();
  MInfo.ToRemove = RemoveFrom::CODLayer;
  CODLayer.add(MInfo.Key, std::move(M));

When removing code:

void removeModule(ModuleInfo &MInfo) {
  switch (MInfo.ToRemove) {
  case RemoveFrom::None:
    break;
  case RemoveFrom::OptimizeLayer:
    OptLayer.removeModule(MInfo.Key);
    break;
  case RemovFrom::CODLayer:
    CODLayer.removeModule(MInfo.Key);
    break;
  }
}

At the moment removal is simpler in my prototype for removable code in
ORCv2: You still create and hold a VModuleKey yourself, but it's an object
that knows how to remove the code for you, so removal looks more like:

auto Key = ES.allocateVModule();
CODLayer.add(Key, std::move(M));
// Do stuff.

// Later.
Key.remove();

Hopefully I can keep it that simple, but there's still a lot of work to do
on this prototype.

Cheers,
Lang.

On Tue, Aug 13, 2019 at 3:17 PM Dibyendu Majumdar <mobile at majumdar.org.uk>
wrote:

> Hi Lang,
>
> On Tue, 13 Aug 2019 at 23:04, Lang Hames <lhames at gmail.com> wrote:
> >
> >> Yes indeed that is what happened. So to prevent that I need to check
> >> if VModuleKey was ever initialized ... how do I do that? I would have
> >> to have to add another flag to track the initialized state.
> >> The reason for it not being initialized is that sometimes I cannot
> >> generate JIT code because some bytecode is not yet supported.
> >
> >
> > I'm not sure I follow. In ORCv1 VModuleKeys are just integers:
> initialization is up to you, and the standard way to get a unique key is to
> always initialize keys by calling ExecutionSession::allocateVModuleKey().
> The intent is that you should use a unique key for each module that you
> add, and keep a copy of the key if it is associated with a module if you
> want to be able to remove that module later. E.g.
> >
> > // Module that I will never want to remove:
> > CODLayer.addModule(ES.createVModuleKey(), std::move(M)); // unique
> throwaway key.
> >
> > // Module that I want to be able to remove later:
> > auto TemporaryModuleKey = ES.createVModuleKey();
> > CODLayer.addModule(TemporaryModuleKey, std::move(M));
> > // Do stuff.
> > CODLayer.removeModule(TemporaryModuleKey);
> >
> > The main use cases of removable modules that I'm aware of are: (1)
> temporary expressions in REPLs, and (2) lower-optimized modules in
> re-optimizing JITs. In the former case you can usually name the key
> individually (as above). In the latter case you usually want to stash it in
> a map or context object somewhere and remove it after you've replaced the
> low-optimization-level code with a higher optimization level.
> >
>
> Okay maybe I am doing something wrong. I am using:
>
> llvm::orc::VModuleKey K = ES->allocateVModule();
>
> My point was that suppose whether I added the module or not in the way
> you suggest, I still need to know which value of they VModuleKey is
> 'invalid'. In the example assume that CODLayer.addModule() is never
> called sometimes. So how do you know whether to call removeModule()?
>
>
> Regards
> Dibyendu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190813/80d02ca0/attachment.html>