similar to: [RFC] MC support for variant scheduling classes.

> On May 10, 2018, at 8:58 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > Hi all, > > The goal of this RFC is to make information related to variant scheduling > classes accessible at MC level. This would help tools like llvm-mca > understand/resolve variant scheduling classes. > > To achieve this goal, I plan to introduce a new class of

From: Andrew Trick [mailto:atrick at apple.com] Sent: 24 January 2014 21:52 To: Daniel Sanders Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: New machine model questions On Jan 24, 2014, at 2:21 AM, Daniel Sanders <Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>> wrote: Hi Andrew, I seem to be making good progress on the P5600 scheduler

Hi Andrew, I seem to be making good progress on the P5600 scheduler using the new machine model but I've got a few questions about it. How would you represent an instruction that splits into two micro-ops and is dispatched to two different reservation stations? For example, I have two reservation stations (AGQ and FPQ). An FPU load instruction is split into a load micro-op which is

Thanks Andrew and Renato, One think I didn't mention, and I should probably made it more explicit in my RFC is that: "the new predicate framework is extensible". That means, developers can extend it by adding new Check predicates. As long as they also teach the PredicateExpander how to do the lowering for those new predicates, then everything should be fine. -- In the RFC I

> On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com> wrote: > > > >> On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >>> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at

On Tue, Mar 6, 2018 at 5:55 AM, Andrew Trick via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com> wrote: > > > > On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at

> On May 11, 2018, at 4:26 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > The goal is to help users defining a predicate the check logic. If we use a TIIPredicate, we specify the logic only once, in a declarative way, and then we let tablegen generate code for us. > > If for some reason, a user doesn't want to use this approach, then they can still

> On Mar 6, 2018, at 4:20 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > To be clear then, resolveSchedClass should be moved from TargetSchedModel into MCSchedModel (which is where I originally wanted it). Any TargetInstrInfo APIs called from SchedPredicate should be moved to MCInstrInfo, which should be straightforward but annoying. > > Personally, I

On 10 May 2018 at 21:58, Andrew Trick <atrick at apple.com> wrote: > Fantastic writeup! It’s great to see so much progress on fundamental > infrastructure. > > My time for LLVM code review is extremely limited. Can someone work with > Andrea to get these patches in? Hi Andrew, Same here, but this has been a long goal for me, too, so I'll do my best. -- cheers,

> On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> When Ahmed and I worked on the decompiler, we first targeted MC. Going to MI was more difficult and really wouldn’t have gotten us a