search for: largestinput

...data structures. We shouldn't need both. I > am okay with transitions being folded into the State class if it results > in significant speedup in DFA generation. Yes, it gives a significant speedup to the emitter. My main concern is to address this: 357: for (unsigned j = 0; j <= LargestInput; ++j) { LargestInput becomes too large. The more resources we introduce in the td file the larger it will be. Given an architecture with n resources, LargestInput will take the maximum value, i.e. 2^(n-1), but valid inputs are just a small subset of [0, LargestInput]. But then please remove th...

...;t need both. I >> am okay with transitions being folded into the State class if it results >> in significant speedup in DFA generation. > > Yes, it gives a significant speedup to the emitter. My main concern is > to address this: > > 357: for (unsigned j = 0; j <= LargestInput; ++j) { > > LargestInput becomes too large. The more resources we introduce in the > td file the larger it will be. Given an architecture with n resources, > LargestInput will take the maximum value, i.e. 2^(n-1), but valid > inputs are just a small subset of [0, LargestInput]. &g...

...; am okay with transitions being folded into the State class if it results >>> in significant speedup in DFA generation. >> >> Yes, it gives a significant speedup to the emitter. My main concern is >> to address this: >> >> 357: for (unsigned j = 0; j <= LargestInput; ++j) { >> >> LargestInput becomes too large. The more resources we introduce in the >> td file the larger it will be. Given an architecture with n resources, >> LargestInput will take the maximum value, i.e. 2^(n-1), but valid >> inputs are just a small subset of [0,...

Committed in r159281. -Anshu On 6/26/2012 3:04 AM, Ivan Llopard wrote: > Hi Anshu, > > I don't have commit access. It applies correctly on trunk, I've just > checked it. Could you please commit it? > > Ivan > > On 26/06/2012 04:44, adasgupt at codeaurora.org wrote: >> Hi Ivan, >> >> Sorry, I should have been more explicit in my last email. The

...@@ -139,6 +152,7 @@ class DFA { public: DFA(); + ~DFA(); // Set of states. Need to keep this sorted to emit the transition table. std::set<State*, ltState> states; @@ -148,9 +162,6 @@ stateTransitions; State *currentState; - // Highest valued Input seen. - unsigned LargestInput; - // // Modify the DFA. // @@ -179,7 +190,7 @@ // -// Constructors for State, Transition, and DFA +// Constructors and destructors for State, Transition, and DFA // State::State() : stateNum(currentStateNum++), isInitial(false) {} @@ -189,15 +200,26 @@ stateNum(currentStateNu...

Hi Ivan, > I missed last 2 commits made by Alexey. Following his advices, I > updated the patch. It should be ok now. > Thanks Anshu! > > I've recently added more functional units to our Schedule.td and the > generation time became painfully long. In fact, the main problem was > in writeTableAndAPI(). I propose another patch to fix it: > - Fixed memory leaks. > -

Hi Anshu, I don't have commit access. It applies correctly on trunk, I've just checked it. Could you please commit it? Ivan On 26/06/2012 04:44, adasgupt at codeaurora.org wrote: > Hi Ivan, > > Sorry, I should have been more explicit in my last email. The patch looks > good to me. Please check that it applies on trunk and go ahead and commit. > > Thanks > -Anshu