BaseYinYang with ManifestBased.
BaseYinYang with TypeTag.
Base trait for code generating DSLs.
Marker trait for DSLs in which all holes are used for optimizations and therefore lifted.
Marker trait for DSLs in which all holes are used for optimizations and therefore lifted. This implies that if a DSL program has at least one hole, it won't be compiled at compile time. All variables are treated as RequiredStaticCompVar with the default guard.
NOTE: DSLs that inherit this trait will not be reflectively instantiated at compile time.
Marker trait for DSLs in which no holes are used for optimizations, so all holes are treated as constants instead of being lifted.
Marker trait for DSLs in which no holes are used for optimizations, so all holes are treated as constants instead of being lifted. This implies that a code generating DSL will always be compiled at compile time. In other words, all variables are treated as NonCompVar.
NOTE: DSLs that inherit this trait will not be reflectively instantiated at compile time.
A guard defines how compilation variables are guarded, e.g.
A guard defines how compilation variables are guarded, e.g. when recompilation is triggered. It encapsulates the body of an anonymous function deciding whether two arguments named "t1" and "t2" of type Any are equivalent as far as the DSL optimizations are concerned, or whether the program has to be recompiled.
Marker trait for DSLs in which identifying holes are done by lifted type information.
Marker trait for DSLs in which identifying holes are done by lifted type information.
NOTE: DSLs that inherit this trait will not be reflectively instantiated at compile time.
Base trait for interpreted DSLs.
Base trait for interpreted DSLs.
Trait that statically checked DSLs need to inherit .
Trait that statically checked DSLs need to inherit . NOTE: DSLs inheriting this trait will always be reflectively instantiated at compile time.
A VarType describes the free variables of a DSL program that are used in compilation.
A VarType describes the free variables of a DSL program that are used in
compilation. Variables which aren't used in any compilation decisions should
be marked as NonCompVar
and will result in holes in the compiled DSL.
There are four CompVar
types, each with an associated guard function that
decides when recompilation is triggered.
Firstly, a variable can be static or dynamic. If it is static, then values with different executions always need recompilation. But if for example we have multiplication variants for sparse and dense matrices, then we only need to recompile when the new value doesn't fall into the same category. So variables need to be marked as dynamic if some values don't require recompilation but should lead to a different execution anyhow (they appear as variables in the compiled code instead of being fixed to the value used when compiling). In this case, the DSL needs to implement the function: LiftEvidence[T: TypeTag, Ret].mixed(v: T, hole: Ret): Ret The value v is used for optimization decisions (e.g. sparse vs. dense matrix), and the hole as variable in the generated code.
The second characteristic is whether a variable is required for compilation or optional. For required variables, optimized code will always be generated. For optional variables, runtime statistics are being collected and optimized code is only generated when a variable is sufficiently stable, otherwise generic code with a variable should be generated. Optional variables are also represented as mixed nodes in the DSL body. The stable variables are passed as a set of holeIds to the generateCode method and can be treated like required variables, respecting their static/dynamic nature, and will be guarded with the provided guard function. For the unstable ones, generic code only using the hole and not the value of the mixed node has to be generated. The value will not be guarded.
Member method-based virtualization of the Any
API.
Member method-based virtualization of the Any
API.
This trait provides implementations of the infix methods
corresponding to the Any
API that delegate to virtualized method
calls on the first argument of the infix method.
Example: When faced with an expression of the form x == y
, the
ch.epfl.yinyang.transformers.LanguageVirtualization
transformation (or the @virtualized
macro annotation)
will generate a method call:
infix_==(x, y)
. This method call will be bound to an
implementation based on normal rules of scoping. If it binds to
the one in this trait, the corresponding macro will rewrite it to
x.==(y)
.
Member method-based virtualization of the AnyRef
API.
Member method-based virtualization of the AnyRef
API.
This trait provides implementations of the infix methods
corresponding to the AnyRef
API that delegate to virtualized
method calls on the first argument of the infix method.
Example: When faced with an expression of the form x.eq(y)
, the
ch.epfl.yinyang.transformers.LanguageVirtualization
transformation (or the
@virtualized
macro annotation) will generate a method call:
infix_eq(x, y)
. This method call will be bound to an
implementation based on normal rules of scoping. If it binds to
the one in this trait, the corresponding macro will rewrite it to
x.eq(y)
.