similar to: [LLVMdev] [PATCH] Refactoring the DFA generator

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

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

Hi Anshu, Thanks for reviewing this. I added a top comment for AddInsnClass and I fixed the violation of column numbers. On 15/06/2012 21:31, Anshuman Dasgupta wrote: > Hi Ivan, > > The patch looks good to me. I have a couple of minor comments: > > +void State::AddInsnClass(unsigned InsnClass, > Add a top level comment describing the function > > + std::map<State*,

Hi Ivan, The patch looks good to me. I have a couple of minor comments: +void State::AddInsnClass(unsigned InsnClass, Add a top level comment describing the function + std::map<State*, std::set<Transition*, ltTransition>, ltState> stateTransitions; You should be able to use SmallSet here. Also, this line exceeds 80 columns. On a related note, is the CachedTable mechanism in

Hi Anshu, Just in case you have forgotten this thread ;-). Is this patch ok to commit or does it not apply to trunk properly ? I can fix it if that's the problem. Ivan On 20/06/2012 19:33, Anshuman Dasgupta wrote: > > > Thanks for reviewing this. I added a top comment for AddInsnClass > and I fixed the violation of column numbers. > > Great. Looks good to me. > >

I missed last 2 commits made by Alexey. Following his advices, I updated the patch. It should be ok now. Ivan On 27/06/2012 21:42, Anshuman Dasgupta wrote: > 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.

> Thanks for reviewing this. I added a top comment for AddInsnClass and I fixed the violation of column numbers. Great. Looks good to me. > IMO, it wil be nice to keep it alive for performance comparisons. Given the overall performance > is rather determined by transition searches on the current state, for small DFA tables may not be a win > and it may still be the case for

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 > Hi Anshu, > > Just in case you have forgotten this thread ;-). Is this patch ok to > commit or does it not apply to trunk properly ? > I can fix it if that's the problem. > > Ivan > > On

Ivan, Thanks for working on the DFA generator. I'll take a look at the changes in detail but from your description, I like the general nature of the modifications. -Anshu --- Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 6/14/2012 8:22 AM, Ivan Llopard wrote: > Hi, > > I've refactored the DFA generator in TableGen because it takes too > much

Hi Jonas, > It is interesting to find this in the ARM backend, considering your answer. The ARM backend doesn't use the DFA packetizer. It's only used by Hexagon. At this point, there is no plan to address thisin the DFA packetizer since none of the supported targets needthe functionality. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,

Hi Anshu, Thanks again for your feedbacks. On 24/08/2012 17:01, Anshuman Dasgupta wrote: > 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

Jonas, At this point, the DFA packetizer models a simple VLIW architecture and does not accommodate multiple stages. That's the reason for the behavior you're seeing. -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On Behalf Of *Jonas

Hi Anshu, Would there be any interest in extending this algorithm to handling more extensive models, such as VLIW scheduling based on FU's and bundle space... ie handle multiple stages ? I might do it and commit, if there is acceptance and guidance... Jonas ________________________________ From: Anshuman Dasgupta [mailto:adasgupt at codeaurora.org] Sent: Tuesday, February 12, 2013 4:47 PM

Ivan, Thanks for working on the patch. It looks good to me except for the removal of the Transition class: > (1) Should I completely remove Transition and create a map structure in State (input, state) to replace them? Yes, please remove the Transition class and create a map structure in State instead of TransitionSet. Thanks -Anshu On 8/25/2012 6:42 AM, Ivan Llopard wrote: > Hi

On 28/08/2012 00:21, Anshuman Dasgupta wrote: > Ivan, > > Thanks for working on the patch. It looks good to me except for the > removal of the Transition class: > > > (1) Should I completely remove Transition and create a map structure > in State (input, state) to replace them? > > Yes, please remove the Transition class and create a map structure in > State

Hi, I looked a bit through the mail archives, and found this question answered in Oct 2011 (see below). It is interesting to find this in the ARM backend, considering your answer. Can you give more information about for example is this a temporary deficiency in the DFAPacketizer? What is the IIC_iMOVi itinerary doing below? Thanks, Jonas Thu Oct 6 15:11:25 CDT 2011: Hello Hal. > Is there

Hi Ivan, The assertion was happening because I wasn't checking after the first attempt failed. The first packet was failing and so it was ended, and then the packetizer attempted to add it to the next packet without checking for available resources. However this highlights probably the real problem - my packetizer is unable to find resources for the first instruction, or any of my

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. > -

> On Nov 9, 2015, at 10:49 AM, Rail Shafigulin <rail at esenciatech.com> wrote: > > On Mon, Nov 9, 2015 at 10:31 AM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: > ----- Original Message ----- > > From: "Rail Shafigulin via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > > To:

I'm considering writing more-detailed itineraries for some PowerPC CPUs that use the 'traditional' instruction grouping scheme. In essence, this means that multiple instructions will stall in some pipeline stage until a complete group is formed, then all will continue. I expect to provide CPU-specific code to help determine when the currently-waiting instructions would form a group.