search for: branchi

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

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

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

[I just got official okay to mention this in public. This was previously announced at Apple's WWDC conference last week.] For those who are interested, Apple announced that they are using the LLVM optimizer and JIT within their Mac OS 10.5 'Leopard' OpenGL stack (which was distributed in beta form to WWDC attendees). LLVM is used in two different ways, at runtime: 1. Runtime

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

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.

...addition of an external "loop mode" option to >>> MCA. If there are no other strong use cases, I would advocate for >>> experimental intrinsics unless people can contribute other example use >>> cases. > In short, I am in agreement and think that handling of branching or loop > constructs should be isolated to the llvm-mca driver/front-end. The > only thing the code regions should be concerned with is identifying > blocks of instructions that will later be used by the front end. > > We can place limitations to how those blocks are formed. For e...

On Tue, 2015-09-08 at 10:24 +0100, Ian Campbell wrote: > Stubdomains When 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

...user does this in the source code via intrinsics (just what this patch is proposing), then there is a chance that optimizations might change the layout of the instructions and confuse the ordering of the MCA intrinsics. Since MCA does not follow branches (MCA just treats a branch as it would a non-branching instruction), it seems that a user should be aware that defining MCA code regions that span multiple blocks might result in an unexpected analysis. While we do not discourage this, it seems like such a case will probably not produce an expected result for the user. We could introduce a warning,...

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

...zations might change the layout of the >> > >> > instructions and confuse the ordering of the MCA intrinsics. >> > >> > >> > >> > Since MCA does not follow branches (MCA just treats a branch as it >> would >> > >> > a non-branching instruction), it seems that a user should be aware >> that >> > >> > defining MCA code regions that span multiple blocks might result >> in an >> > >> > unexpected analysis. While we do not discourage this, it seems >> like >> > >...

...(just what this patch is proposing), then > > there is a chance that optimizations might change the layout of the > > instructions and confuse the ordering of the MCA intrinsics. > > > > Since MCA does not follow branches (MCA just treats a branch as it would > > a non-branching instruction), it seems that a user should be aware that > > defining MCA code regions that span multiple blocks might result in an > > unexpected analysis. While we do not discourage this, it seems like > > such a case will probably not produce an expected result for the user....

...; >> > there is a chance that optimizations might change the layout of the > >> > instructions and confuse the ordering of the MCA intrinsics. > >> > > >> > Since MCA does not follow branches (MCA just treats a branch as it would > >> > a non-branching instruction), it seems that a user should be aware that > >> > defining MCA code regions that span multiple blocks might result in an > >> > unexpected analysis. While we do not discourage this, it seems like > >> > such a case will probably not produce an exp...

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

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