The optimizers form the basis for replacing code fragments. Two optimizers are focused on code expansion and contraction. The former involves replacing individual instructions by a block of MAL code, i.e. a macro call. The latter depicts the inverse operation, a group of instructions is replaced by a single MAL assignment statement, i.e. a orcam call.
The macro facility is limited to type-correct MAL functions, which means that replacement is not essential from a semantic point of view. They could have been called, or the block need not be compressed. It is equivalent to inline code expansion.
The macro and orcam transformations provide a basis to develop front-end specific code generation templates. The prototypical test case is the following template:
function user.joinPath( a:bat[:any_1,:any_2],
b:bat[:any_2,:any_3],
c:bat[:any_3,:any_4]):bat[:any_1,:any_4]
address fastjoinpath;
z:= join(a,b);
zz:= join(z,c);
return zz;
end user.joinPath;
The call optimizer.macro("user", "joinPath") hunts for occurrences of the instruction call in the block in
which it is called and replaces it with the body, i.e. it in-lines the code.
Conversely, the optimizer.orcam("user", "joinPath") attempts to localize a block of two join operations and,
when found, it is replaced by the direct call to joinPath. In turn, type resolution then directs execution
to a built-in function fastjoinpath.
The current implementation is limited to finding a consecutive sequence, ending in a return-statement. The latter is needed to properly embed the result in the enclosed environment. It may be extended in the future to consider the flow of control as well.
The functions subject to expansion or contraction should be checked on 'proper' behavior.
The current implementation is extremely limited. The macro optimizer does not recognize use of intermediate results outside the block being contracted. his should be checked and it should block the replacement, unless the intermediates are part of the return list. Likewise, we assume here that the block has a single return statement, which is also the last one to be executed.
The macro optimizer can only expand functions. Factories already carry a significant complex flow of control that is hard to simulate in the nested flow structure of an arbitrary function.
The orcam optimizer can not deal with calls controlled by a barrier. It would often require a rewrite of several other statements as well.
pattern optimizer.macro(targetmod:str,targetfcn:str):void
address OPTmacro
comment "Inline the code of the target function.";
pattern optimizer.macro(mod:str,fcn:str,targetmod:str,targetfcn:str):void
address OPTmacro
comment "Inline a target function used in a specific function.";
pattern optimizer.orcam(targetmod:str,targetfcn:str):void
address OPTorcam
comment "Inverse macro processor for current function";
pattern optimizer.orcam(mod:str,fcn:str,targetmod:str,targetfcn:str):void
address OPTorcam
comment "Inverse macro, find pattern and replace with a function call.";