Add system for enabling/disabling optimizations

[ayazhafiz]

We should add some method for enabling/disabling optimizations as we prepare for the optimization platform. Right now this can be as simple as enabling/disabling whether operations should be evaluated in the partial evaluator.

Related to #7.

[ayazhafiz]

I don't know what the best design for this would be. The most straightforward is a map of what optimizations should be enabled:

// This can be packed to 1-bit alignments or we can just use an integer with bitflags idk
struct EvaluationOptions {
  add: bool,
  sub: bool,
  // ...
}

struct PartialEvaluator {
  options: EvaluationOptions
}

fn identity_uneval(l: PEResult, r: PEResult, op: Operator) -> PEResult {
  PEResult::fold_unevaluated_binary(l, r, op)
}

impl PartialEvaluator {
  fn eval_fn(&self, op: Operator) -> Fn(PEResult, PEResult, Operator) {
    match op {
      Plus => {
        if self.options.add { |l, r, op| PEResult::fold_binary(l, r, op) } else { identity_uneval }
      }
    }
  }
}

impl Visitor for PartialEvaluator {
  fn visit_binary_expr(&self, item: Expr) {
    let lhs = self.visit_expr(*item.lhs);
    let rhs = self.visit_expr(*item.rhs);
    let eval_fn = self.eval_fn(expr.op);
    eval_fn(lhs, rhs, item.op)
  }
}

I think a better alternative is to construct the function table when the partial evaluator is first created:

// This can be packed to 1-bit alignments or we can just use an integer with bitflags idk
struct EvaluationOptions {
  add: bool,
  sub: bool,
  // ...
}

trait Evaluator {
  pub fn new(options: EvaluationOptions) -> Self;
}

struct PartialEvaluator {
  eval_fn_table: EvalFnRegistry
}

impl Evaluator for PartialEvaluator {
  fn new(options: EvaluationOptions) -> Self {
    Self {eval_fn_table: EvalFnRegistry::from_options(options)}
  }
}

impl Visitor for PartialEvaluator {
  fn visit_binary_expr(&self, item: Expr) {
    let lhs = self.visit_expr(*item.lhs);
    let rhs = self.visit_expr(*item.rhs);
    let eval_fn = self.eval_fn_table.get_operator(expr.op);
    eval_fn(lhs, rhs, item.op)
  }
}

struct EvalFnRegistry {
  add: Fn(PEResult, PEResult) -> PEResult,
  // ...
}

fn identity_uneval(l: PEResult, r: PEResult, op: Operator) -> PEResult {
  PEResult::fold_unevaluated_binary(l, r, op)
}

impl EvalFnRegistry {
  pub fn from_options(options: EvaluationOptions) -> Self {
    let add = if options.add { |l, r| PEResult::fold_binary(l, r, Plus) } else { identity_uneval } 
  }

  pub fn get_binary_operator(&self, op: Operator) -> Fn(PEResult, PEResult, Operator) {
    match op {
      Plus => self.add,
      // ...
    }
  }
}

@luke-bhan what do you think?

[lukebhan]

I don't think we need two separate structs in addition to partial evaluator for this. I think this can be simplified

[ayazhafiz]

Can you suggest a simplification?

[lukebhan]

yea, lemme just handle the other pr rq

[lukebhan]

So wait. If eval_fn is returned false:
does eval_fn(x, y, z) just not run?

[lukebhan]

also why is EvaluatedOptions a struct and not a hash map

[ayazhafiz]

So wait. If eval_fn is returned false:
does eval_fn(x, y, z) just not run?

Yeah, we just return an unevaluated expression.

also why is EvaluatedOptions a struct and not a hash map

So that we strongly type the kind of options we can have.

[lukebhan]

I see, the hashmap is a little different in rust then Id expect. I think your solution makes sense then. However, I think were spending a lot of time on unevaluated implementation when all of this will need to be refactored once we start optimizing. Do you think its worthwhile to investigate that first?

[ayazhafiz]

Yes, it will have to be refactored somewhat but this is kinda the point of the optimization platform: by having a list of rules we can just append a new optimization rule to the list and implement the optimization. I would like to have some end-to-end pipeline in place as the very base groundwork for the app, which is why I suggest this. But I totally agree, we should focus much more time on the optimizations because they are harder and more interesting. I haven’t researched too much yet, but one resource i have been looking to explore more is http://pages.cs.wisc.edu/~horwitz/CS704-NOTES/9.PARTIAL-EVALUATION.html. I will explore more this weekend since I am moving today/tomorrow. If you would like to read up literature on this and propose some algorithms it would be dope :-)

…

________________________________ От: Luke Bhan <notifications@github.com> Отправлено: Friday, May 1, 2020 7:30:20 PM Кому: ayazhafiz/slide <slide@noreply.github.com> Копия: hafiz <ayaz.hafiz.1@gmail.com>; Assign <assign@noreply.github.com> Тема: Re: [ayazhafiz/slide] Add system for enabling/disabling optimizations (#26) I see, the hashmap is a little different in rust then Id expect. I think your solution makes sense then. However, I think were spending a lot of time on unevaluated implementation when all of this will need to be refactored once we start optimizing. Do you think its worthwhile to investigate that first? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<https://github.com/ayazhafiz/slide/issues/26#issuecomment-622656110>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE6GL6RP7WV4AQLQV2L6ZHTRPOATZANCNFSM4MXNRPOQ>.

[lukebhan]

Yes, Ill look into it. Also, be safe with the move out.

[ayazhafiz]

Thanks... got some face masks and gloves.

…

On Fri, May 1, 2020 at 7:42 PM Luke Bhan ***@***.***> wrote: Yes, Ill look into it. Also, be safe with the move out. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <https://github.com/ayazhafiz/slide/issues/26#issuecomment-622657483>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6GL6TV36MLFMUG5RMV5JLRPOB73ANCNFSM4MXNRPOQ> .