similar to: [LLVMdev] Instruction Latencies After Scheduling

Hi   I would like to get the execution trace output from LLVM. I noticed LLVM has "llvm-3.0.src/lib/Analysis/Trace.cpp" and "llvm-3.0.src/include/llvm/Analysis/Trace.h". Any idea on the functionality of Trace.cpp and how to invoke the dump() method in command line so that the execution traces can be observed. Thanks.   With regards Yan Lin Aung -------------- next part

Hi All, Is there a way to dump the global variables, which are accessed (read/written to) by each function within the LLVM function pass? Any pointers on how that info can be extracted in LLVM for each function in the application? Thanks. Regards, Yan Lin Aung -------------- next part -------------- An HTML attachment was scrubbed... URL:

I overrode getInstrLatency and did some printing to see what is available there. It looks like the registers are still virtual at that point when getInstrLatency is called - is that correct? (we needed to make some decisions based on actual registers that have been assigned since some registers are reserved as address space pointers and we could vary the latency based on which address space

On Fri, 02 Mar 2012 13:49:48 -0800 Andrew Trick <atrick at apple.com> wrote: > On Mar 2, 2012, at 9:01 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > Hello, > > > > I am interested in writing an analysis pass that looks at the stride > > used for loads in a loop and passes that information down so that it > > can be used by the instruction

On Mar 2, 2012, at 9:01 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Hello, > > I am interested in writing an analysis pass that looks at the stride > used for loads in a loop and passes that information down so that it > can be used by the instruction scheduler. The reason is that if the > load stride is greater than the cache line size, then I would expect > the load

In our architecture loads from certain memory locations take a long time to complete (on the order of 150 clock cycles). Since we don't have a way to tell at compile time if the address being loaded from lies in slow or fast memory, I've gone ahead and made all of the load numbers high, such as: InstrItinData< II_LOAD1, [InstrStage<150, [AGU]>]>, However, I see that

Does anybody know how to specify instruction latency in the itinerary scheduling model? For some reason no matter what I do I get a latency of 1. -- Rail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151111/161bd6cb/attachment.html>

Hi, In LLVM, llc can be used to generate native assembly code for a selected target processor (-march=target). I would like to extract/build CFG from the generated assembly code. Is this possible in LLVM? Anyone knows how to extract CFG from the assembly code? Thanks. With regards Yan Lin

Hello, I am interested in writing an analysis pass that looks at the stride used for loads in a loop and passes that information down so that it can be used by the instruction scheduler. The reason is that if the load stride is greater than the cache line size, then I would expect the load to always miss the cache, and, as a result, the scheduler should use a much larger effective latency when

On 03/15/2018 10:04 AM, Guillaume Chatelet via llvm-dev wrote: > [You can find an easier to read and more complete version of this RFC > here > <https://docs.google.com/document/d/1QidaJMJUyQdRrFKD66vE1_N55whe0coQ3h1GpFzz27M/edit?ts=5aaa84ee#>.] > > Knowing instruction scheduling properties (latency, uops) is the basis > for all scheduling work done by LLVM. > > >

Sounds like a very useful tool.  Thank you for contributing. Taking a step back and looking at the big picture, combining this with the recently contributed llvm-mca dramatically improves our scheduling and performance analysis story.  Being able to take a snippet of code on a particular machine, measure latency/throughput/ports for each instruction (this tool), and then analyze the entire

On 03/15/2018 10:49 AM, Clement Courbet wrote: > > > On Thu, Mar 15, 2018 at 4:41 PM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 03/15/2018 10:04 AM, Guillaume Chatelet via llvm-dev wrote: >> [You can find an easier to read and more complete version of this >> RFC here >>

On Tue, 2011-12-20 at 10:35 -0600, Hal Finkel wrote: > On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > > load-fadd-store chains to schedule. A store takes two cycles to > > > clear > >

On Dec 20, 2011, at 10:29 AM, Hal Finkel wrote: > On Tue, 2011-12-20 at 10:35 -0600, Hal Finkel wrote: >> On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: >>> >>> On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: >>> >>>> Here's my "thought experiment" (from PR11589): I have a bunch of >>>> load-fadd-store chains to

On 09/05/2013 18:25, Andrew Trick wrote: > > On May 9, 2013, at 4:02 AM, Fraser Cormack <fraser at codeplay.com > <mailto:fraser at codeplay.com>> wrote: > >> I have an instruction that takes no operands, and produces two >> results, in two consecutive cycles. >> >> I tried both of the following to my Schedule.td file: >> >>

On Oct 21, 2011, at 12:15 AM, James Molloy wrote: > Hi Andy, > > Could you describe how this would be done? In the current ARM itineraries > (say C-A9 for example), the superscalar issue stage is modelled as taking 1 > cycle. If it were to take 2 cycles instead, as far as I can tell the hazard > analyser would stall because both FU's would be acquired. > > I would

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'

On Thu, Mar 15, 2018 at 4:41 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 03/15/2018 10:04 AM, Guillaume Chatelet via llvm-dev wrote: > > [You can find an easier to read and more complete version of this RFC here > <https://docs.google.com/document/d/1QidaJMJUyQdRrFKD66vE1_N55whe0coQ3h1GpFzz27M/edit?ts=5aaa84ee#> > .] > > Knowing

Hi Ghassan, this is very interesting, however... > We are currently working on revising a journal article that describes our work > on pre-allocation scheduling using LLVM and have some questions about LLVM's > pre-allocation scheduler. The answers to these question will help us better > document and analyze the results of our benchmark tests that compare our > algorithm with

On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > load-fadd-store chains to schedule. A store takes two cycles to > > clear > > its last pipeline stage. The fadd takes longer to compute its result > > (say 5