search for: branchy

Hi Alastair, In addition to your planned tasks, you might want to put in some work to ensure branch probabilities are not lost during optimization. One known issue is LLVM optimizer can turn branchy code into switch statements and it would completely discard probability. Here is a simple example: static void func2(int N, const int *a, const int *b, int *c) __attribute__((always_inline)); void func4(int N, const int *a, const int *b, int *c) __attribute__((noinline)); void func8(int N, const...

I think it’s generally true that whenever branches can reliably be predicted branching is faster than a cmov that involves speculative execution, and I would guess that your assessment regarding looping on input values is probably correct. I believe the code that actually creates most of the transformation you’re interested in here is in SelectionDAGLegalize::ExpandNode() in LegalizeDAG.cpp. The

On Wed, 2010-06-09 at 17:30 +0200, orthochronous wrote: > Hi, > > I've been thinking about how to implement a framework for attempting > instruction scheduling of small blocks of code by using (GA/simulated > annealing/etc) controlled timing-test-evaluations of various > orderings. This sounds interesting. > (I'm particularly interested small-ish numerical inner

Hi all, In light of the expected removal of ProfileInfo this is a request for comments on the next few items that I now plan to work on for GSoC. Planned tasks: #0 Add support for determining branch weight metadata by profiling At the absolute minimum this will require writing a new profile loader which will set branch weight metadata based on profiling data. #1 Optionally use profiling

Hi, I've been thinking about how to implement a framework for attempting instruction scheduling of small blocks of code by using (GA/simulated annealing/etc) controlled timing-test-evaluations of various orderings. (I'm particularly interested small-ish numerical inner loop code in low-power CPUs like Atom and various ARMs where there CPU doesn't have the ability to

ocfs2 fans! The ocfs2.git tree is a little bored with life in the suburbs, and so it is moving to the city! Starting today, I'll be feeding it and watering it at git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2.git. All your usual branchy goodness will be there. Don't worry, Mark still is my co-maintainer. He's done all the heavy tree lifting for over two years, and its high time I shared the load. We'll both review patches, etc, but I'll be the one merging them and pushing them. Pull: git://git.kernel.org/pub/sc...

...dees). LLVM is used in two different ways, at runtime: 1. Runtime code specialization within the fixed-function vertex-processing pipeline. Basically, the OpenGL pipeline has many parameters (is fog enabled? do vertices have texture info? etc) which rarely change: executing the fully branchy code swamps the branch predictors and performs poorly. To solve this, the code is precompiled to LLVM .bc form, from which specializations of the code are made, optimized, and JIT compiled as they are needed at runtime. 2. OpenGL vertex shaders are small programs written using a famil...

Hi Philip, On Fri, Mar 2, 2018 at 6:06 PM, Philip Reames <listmail at philipreames.com> wrote: > 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 modeling fe...

Thanks David for the comments. Sorry for the late reply. On Mon, Aug 23, 2010 at 11:52 PM, David A. Greene <greened at obbligato.org> wrote: > Che-Liang Chiou <clchiou at gmail.com> writes: > >> Hi there, >> >> Thank Nick for kindly reviewing the patch.  Here is the link to the >> source code of the PTX backend; it would help Nick review the patch.

Hi Matt, I can see a near future where perf-analysis tooling uses branch history profiler captures to determine how often loops/branches are taken and feeds that into llvm-mca, especially for hot/branchy loop analysis reports etc. Are you confident that your approach will be easily extendable for this? Similarly, being able to generally embed the profile markers in object libraries for reuse is going to be important for some people - I'd like to see more of a plan of how this will be achie...

...en I passed these notes around internally for sanity checking we ended up discussing this issue, since we decided it would be better to move this to xen-devel I'm quoting the thread below with permission. It was a bit tricky to flatten the thread into a single mail, but it wasn't too "branchy" so I think this will be ok. Hopefully I've not misrepresented what anyone said by how I've arranged it here... > =========== > > Hard to do in a packaging environment (is really its own partial > architecture). Rump kernels are no different in this regard. > > No c...

...ify this aspect. > > As a side note: at the moment, llvm-mca doesn't know how to deal with > branches. So, for simplicity we could force code regions to only contain > instructions from a single basic block. > > However, In future we may want to teach llvm-mca how to analyze branchy > code too. For example, we could introduce a simple control-flow analysis in > llvm-mca, and use an external "branch trace" information (for example, a > perf trace generated by an external tool) to decorate branches with with > branch probabilities (similarly to what we curr...

Che-Liang Chiou <clchiou at gmail.com> writes: > Hi there, > > Thank Nick for kindly reviewing the patch. Here is the link to the > source code of the PTX backend; it would help Nick review the patch. > http://lime.csie.ntu.edu.tw/~clchiou/llvm-ptx-backend.tar.gz Great! > I decided to take the code generator approach (referred to as codegen > approach) rather than C

Introduction ----------------- Currently llvm-mca only accepts assembly code as input. We would like to extend llvm-mca to support object files, allowing users to analyze the performance of binaries. The proposed changes (which involve both clang and llvm) optionally introduce an object file section, but this can be stripped-out if desired. For the llvm-mca binary support feature to be useful, a

...licity we could force code regions to only >> > >> contain >> > >> > > instructions from a single basic block. >> > >> > > >> > >> > > However, In future we may want to teach llvm-mca how to analyze >> > >> branchy >> > >> > > code too. For example, we could introduce a simple control-flow >> > >> analysis in >> > >> > > llvm-mca, and use an external "branch trace" information (for >> > >> example, a >> > >> >...

...at the moment, llvm-mca doesn't know how to deal with > > > branches. So, for simplicity we could force code regions to only > contain > > > instructions from a single basic block. > > > > > > However, In future we may want to teach llvm-mca how to analyze branchy > > > code too. For example, we could introduce a simple control-flow > analysis in > > > llvm-mca, and use an external "branch trace" information (for example, > a > > > perf trace generated by an external tool) to decorate branches with > with > &g...

...gt; >> > > branches. So, for simplicity we could force code regions to only > >> contain > >> > > instructions from a single basic block. > >> > > > >> > > However, In future we may want to teach llvm-mca how to analyze > >> branchy > >> > > code too. For example, we could introduce a simple control-flow > >> analysis in > >> > > llvm-mca, and use an external "branch trace" information (for > >> example, a > >> > > perf trace generated by an external tool...

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 modeling fetch, decode, or predictio...

Xen upstream BoF ================ We had a discussion around Xen and packaging at Debian's annual developer conference (Debconf) a few weeks back: https://summit.debconf.org/debconf15/meeting/279/xen-upstream-bof/ These are my notes, I think there is probably stuff of interest to most distro people, not just Debian folks. The session was scheduled in a small, out of the way, room. Around 2

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 we are interested in the feedback from the community, and we also believe that other people might be interested in a tool like