similar to: [LLVMdev] Code Organization

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 scheduling predicates named MCSchedPredicate. An MCSchedPredicate allows the definition of boolean expressions with a well-known semantic, that

Hi Andrew, Thanks for the feedback! On Fri, Mar 2, 2018 at 1:16 AM, Andrew Trick <atrick at apple.com> wrote: > > On Mar 1, 2018, at 9:22 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> > wrote: > > Hi all, > > At Sony we developed an LLVM based performance analysis tool named > llvm-mca. We > currently use it internally to statically measure the

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 May 30, 2013, at 11:35 AM, Jafar J <pluck90 at hotmail.com> wrote: > Hi Jim, > > The idea of reducing the switching activity between the instructions works by reducing the hamming distance between tow consecutive binary strings across the basic block, or reducing the number of the different bits between two consecutive instructions. This is why I need the exact complete

Reading through this last night got be thinking about how to model control flow.  Given most of my source code tends to be very branchy, be limited to straight line code is quite restrictive.  The main thing is that it requires a lot of hand simplification which can be rather error prone at times. It occurs to me that we could remove the restriction around branches without necessarily fully

Hi Andrea, Thanks for this great RFC ! I've put some high-level comments here, and I'll give more focused comments in the review on Phabricator. On Thu, Mar 1, 2018 at 6:22 PM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > Hi all, > > At Sony we developed an LLVM based performance analysis tool named > llvm-mca. We > currently use it internally to

Hi, Here's one of my proposals for GSoC 2012. What do you think? Chip Project Title: Table-Driven Decompilation Abstract: Over the years, the LLVM family has grown to include nearly every type of build tool in existence. One of the few missing is a decompiler. LLVM's TableGen tool could potentially accelerate development of such a tool; most backends already have the information needed

Personally, I think we should add this. I've personally been annoyed that it is difficult to convince gas to use the short jump encoding. If you use just the right kinds of labels, it uses the short encoding, but apparently because of -mc-relax-all, that won't actually work with clang either. It's all quite complicated, and we should just expose a simple way for the user to ask for

> On Mar 1, 2018, at 9:22 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > Hi all, > > At Sony we developed an LLVM based performance analysis tool named llvm-mca. We > currently use it internally to statically measure the performance of code, and > to help triage potential problems with target scheduling models. We decided to > post this RFC because

Could you expand on this a bit? I see from my build directory that llvm-tblgen.exe was built before the Target/* .inc files. It sounds like you're saying that something has to be built between the .exe and the .inc files. At 8/4/2020 02:44 PM, Chris Lattner wrote: >> On Aug 4, 2020, at 11:31 AM, Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>

On 4/4/2012 12:08 AM, Charles Davis wrote: > Proposal: > Since its humble beginnings in 2001, LLVM has grown from a simple compiler toolkit to an entire family of build tools. Currently, it includes an assembler, a disassembler, a JIT, a C compiler, a debugger, an archiver, various tools for analyzing object files, and even a linker. In fact, just about the only tool missing from this set

Andrew Trick <atrick at apple.com> writes: >> Ok, but that doesn't answer the question. Is SchedulerDAG going away? >> If so, what's the timeframe for that? 3.2? > > SchedulerDAG is used for both SD scheduling and MI scheduling. It's not going away. Oh! That's good news! > SD scheduling is not going away in 3.2--it will be the first release with MI

On May 9, 2012, at 8:34 AM, dag at cray.com wrote: > Andrew Trick <atrick at apple.com> writes: > >>> When I asked about enhancing scheduler heuristics a month or so ago, I >>> got a response about a MachineInstr scheduler and that that was the way >>> of the LLVM future. Is that so? Is the ScheduleDAG going away? >> >> You sent a lengthy RFC

On Apr 26, 2013, at 3:53 AM, Martin J. O'Riordan <Martin.ORiordan at movidius.com> wrote: > I am migrating the llvm/clang derived compiler for our processor from the > v3.1 to v3.2 codebase. This has mostly gone well except that instruction > latency scheduling is no longer happening. > > The people who implemented this previously sub-classed 'ScheduleDAGInstrs'

(Sorry about the wall of text, it ended up as a brain dump of a bunch of backend-related documentation that I know about/have bookmarked in the past. Hopefully there's something useful in there.) If you haven't stumbled across them already, these might be helpful: http://llvm.org/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf http://jonathan2251.github.io/lbd/

Hi Jim, The idea of reducing the switching activity between the instructions works by reducing the hamming distance between tow consecutive binary strings across the basic block, or reducing the number of the different bits between two consecutive instructions. This is why I need the exact complete encoding in plain 0’s and 1’s, to be as precise as possible during the scheduling process. I did

> On Nov 13, 2018, at 08:01, David Greene <dag at cray.com> wrote: > > Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> That's an interesting idea. Certainly tablegenerating InstCombine >> ought to be possible and sharing code sounds like it ought to be >> doable. MIR and IR are pretty similar especially after IRTranslator

> 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

Andrew Trick <atrick at apple.com> writes: >> When I asked about enhancing scheduler heuristics a month or so ago, I >> got a response about a MachineInstr scheduler and that that was the way >> of the LLVM future. Is that so? Is the ScheduleDAG going away? > > You sent a lengthy RFC on Apr 20 that demonstrated you aren't > following developments on trunk.

On Thu, 2004-09-02 at 00:04, Vladimir Merzliakov wrote: > I resend email with updated (after mass header move) log examples. > > > LLVM build without big problems in obj dir == src dir case (for example, > > last night tester build) > > But I have problem with building CVS version LLVM in obj dir != src dir > > case. I *only* build with obj dir != src dir and