ymand wrote: > > Draft to demo how we can pull out the boolean model. Let's discuss > > specifics of namings, location, etc. > > Not sure -- do you mean let's wordsmith names now, or do you mean we should > discuss naming and location, but that should happen after we've talked about > the general approach?
Either way -- I just meant that I'm not tied to the particulars included in the draft. > > The purpose of this refactoring is to enable us to compare the performance > > of different boolean models. In particular, we're interested in > > investigating a very simple semantic domain of just the booleans (and Top). > > Can you expand on how we would swap in a different boolean model? > > * Just put `#ifdef`s in the various functions in `bool_model`? > * Provide different namespaces containing different boolean models, then in > `namespace bool_model`, do `using namespace my_desired_bool_model`? > * Something else? For starters, the namespace approach. That will give us a simple way to experiment with alternatives. But, next step is to turn this namespace into a derivative of `DataflowModel` -- we'll just need to extend that interface to support `transferBranch`. Additional alternatives: 1. template parameter -- make the boolean model a static parameter of the overall system. This sounds like a nightmare, to be blunt, forcing a huge amount of code into templates and massive rewriting. Let's not. 2. multiple models -- the boolean model actions occur inside functions that are already parameterized. If we would support multiple models, then we could simply remove the boolean modeling altogether from the core and bundle it up as a standalone model. That is, the core will not concern itself with boolean modeling. I like this for the long term, but don't want to block on this for now. > > I would favour a model that's as simple as possible -- I don't think we want > to use template parameters, for example -- and what you have here looks like > it's intended to be simple. I'm just not sure exactly where this is intended > to go? > > > In the process, the PR drastically simplifies the handling of terminators. > > This cleanup can be pulled out into its own PR, to precede the refactoring > > work. > > I like the cleanup, and I think pulling it out into a separate patch is a > good idea because a) it's unrelated to the rest of this patch, and b) it can > land today, without further discussion needed (IMO). Will do! https://github.com/llvm/llvm-project/pull/82950 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
