roadrunner  2.6.0
Fast simulator for SBML models
Public Member Functions | List of all members
rrllvm::ModelGeneratorContext Class Reference

All LLVM code generating objects basically need at a minimum three things to operate: More...

#include <ModelGeneratorContext.h>

Public Member Functions

 ModelGeneratorContext (const libsbml::SBMLDocument *_doc, unsigned options, std::unique_ptr< Jit > jitEngine)
 attach to an existing sbml document, we borrow a reference to this doc and DO NOT take ownership of it.
 
 ModelGeneratorContext ()
 does not attach to any sbml doc, More...
 
const LLVMModelDataSymbolsgetModelDataSymbols () const
 
const LLVMModelSymbolsgetModelSymbols () const
 
const libsbml::SBMLDocument * getDocument () const
 
const libsbml::Model * getModel () const
 
const std::vector< libsbml::ASTNode * > * getPiecewiseTriggers () const
 
size_t getNumPiecewiseTriggers () const
 
JitgetJitNonOwning () const
 
void transferObjectsToResources (std::shared_ptr< rrllvm::ModelResources > modelResources)
 A lot can go wrong in the process of generating a model from an sbml doc. More...
 
bool getConservedMoietyAnalysis () const
 
bool useSymbolCache () const
 
unsigned getOptions () const
 
RandomgetRandom () const
 get a pointer to the random object. More...
 

Detailed Description

All LLVM code generating objects basically need at a minimum three things to operate:

1: sbml Model - what to process 2: llvm Context - all llvm functions need this, manages llvm memory 3: llvm Module - where the generated code will go

Code generators also need to know the symbols that are in the sbml doc. These could be re-determined in each code gen, but wastefull. The symbols can be thought of as the first pass of the compiler, so all symbols are determined ahead of time before any code generation.

They also make use of an llvm IRBuilder, one of these could be allocated in each code gen object, but that would be wasteful, so we use a single one per sbml compilation, and each code gen just resets the builder insert point, that is what is was designed to do.

So, that leaves us with 5 object that are needed by code generators. Should all code gens have all 5 args passed to thier ctors? There is much talk about how context objects are evil, however this one is NOT inteneded to grow, only store the absolute minimun information that all code generators need.

This class basically functions as a set of ivars if all code generators were methods on a single code gen class.

TODO doc wise discuss the problems with context objects, and why this one address all the concerns.

TODO document memory managment, engine owns model, ...

Constructor & Destructor Documentation

◆ ModelGeneratorContext()

rrllvm::ModelGeneratorContext::ModelGeneratorContext ( )

does not attach to any sbml doc,

useful for testing out LLVM functionality.

Member Function Documentation

◆ getRandom()

Random * rrllvm::ModelGeneratorContext::getRandom ( ) const

get a pointer to the random object.

The random object exists if the document has the distrib package, is null otherwise.

◆ transferObjectsToResources()

void rrllvm::ModelGeneratorContext::transferObjectsToResources ( std::shared_ptr< rrllvm::ModelResources >  modelResources)

A lot can go wrong in the process of generating a model from an sbml doc.

This class is intended to be stack allocated, so when any exception is thrown in the course of model generation, this class will clean up all the contexts and execution engines and so forth.

However, when a model is successfully generated, we need a way to give it the exec engine, and whatever other bits it requires.

So, this method exists so that the generated model can steal all the objects it needs from us, these object are transfered to the model, and our pointers to them are cleared.


The documentation for this class was generated from the following files: