How to represent conditional compare in RTL?
Hi Richard, After adding some new ops, I can keep the conditional compare to the end of tree-level optimization. As tests, I expand conditional compare to BIT_AND_EXPR/BIT_IOR_EXPR, which still depend on later "combine" pass to combine them. Is it possible to expand it to *cmp_and/*cmp_ior like patterns? What's the expected RTL representation for conditional compare after expand and before combine? Thanks! -Zhenqiang ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 21 - 24 May 2013
== Progress == * Performed investigation on gdb7.6 test suite failures and untested test cases. * Updated JIRA enteries with test suite failures on arm to track progress. * Wrote an automation script for selection of individual test cases from a text file. * Got the gdb.dwarf2 test suite patch reviewed from Matt and Will. * Day off on Friday. == Plan == * Finish up initial investigation on gdb7.6 test suite results. * Complete updates of JIRA enteries after investigation on test suite results in complete. * Start work on integration of different testing scripts written in past couple of months. * Send gdb.dwarf2 test suite patch upstream. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Debuggin from Eclipse
Hello Paul, I would suggest you to build a binary of your project with debug info and no optimization using linaro toolchain from commandline. This will rule out any overridden options by eclipse. If you are using a jtag connection for debugging it could be problem with your probe configuration as well. Thanks! -- Omair On 24 May 2013 23:24, Paul Claessen wrote: > Greetings, > > ** ** > > I’m using the Linaro tool chain with Eclipse (Juno) (under Windows) and > openOCD to write firmware for an STM32F20x based design (using an ST-Link2 > debugger). > > ** ** > > In general, that all works fairly well. > > The part I’m having problems with is debugging (step-in, etc) from Eclipse. > > > The execution flow seems chaotic when single stepping through C code: it > skips statements, it jumps into the middle of a function, then returns to > the start of a function, it loops over certain statements (while there’s no > loop in the code), etc. (It’s close to useless). > > ** ** > > I have seen this behavior with other IDE’s and tool chains when code was > built with optimization turned on. > > However, I specify ‘no optimization’ (-O0) when I build my code. > > ** ** > > My questions: > > **a) **Is there some implicit optimization being done in the > compiler, even though I tell it not to do so, which may affect proper > debugging? > > **b) **Are other people using Eclipse (Juno) and are they seeing > the same issue? Are there any known ways to fix this chaotic debugger > behavior? > > ** ** > > Kind regards, > > ** ** > > ~ Paul Claessen > > ** ** > > ___ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-toolchain > > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Malloc usage
All, In the Toolchain Working Group Mans has been doing some examination of SPEC 2000 and SPEC 2006 to see what C Library (glibc) routines impact performance the most, and are worth tuning. This has come up with two areas we consider worthy of further investigation: 1) malloc performance 2) Floating-point rounding functions. This email is interested with the first of these. Analysis of malloc shows large amounts of time is spent in executing synchronization primitives even when the program under test is single-threaded. The obvious 'fix' is to remove the synchronization primitives which will give a performance boost. This is, of course, not safe and will require reworking malloc's algorithms to be (substantially) synchronization free. A quick Google suggests that there are better performing algorithms available (TCMalloc, Lockless, Hoard, &c), and so changing glibc's algorithm is something well worth investigating. Currently we see around 4.37% of time being spent in libc for the whole of SPEC CPU 2006. Around 75% of that is in malloc related functions (so about 3.1% of the total). One benchmark however spends around 20% of its time in malloc. So overall we are looking at maybe 1% improvement in the SPEC 2006 score, which is not large given the amount of effort I estimate this is going to require (as we have to convince the community we have made everyone's life better). So before we go any further I would like to see what the view of LEG is about a better malloc. My questions boil down to: * Is malloc important - or do server applications just implement their own? * Do you have any benchmarks that stress malloc and would provide us with some more data points? But any and all comments on the subject are welcome. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Malloc usage
On 28 May 2013 12:03, Matthew Gretton-Dann wrote: > So before we go any further I would like to see what the view of LEG is > about a better malloc. My questions boil down to: > > * Is malloc important - or do server applications just implement their own? The Apache web server manages its heap allocations with differently scoped pools, i.e., per-request, per-session, per-thread. This allows it for instance to free() a whole request pool at once when it has finished serving a request instead of going through each of the allocations and freeing them one by one. PHP's Zend core has an elaborate memory management layer which does some similar tricks. That means I don't expect malloc() to be as dominant in a real-world *web* server application. > * Do you have any benchmarks that stress malloc and would provide us with > some more data points? > Not right now, but if we notice it anywhere near the top in the perf trace, we will let you know about it. -- Ard. > But any and all comments on the subject are welcome. > > Thanks, > > Matt > > -- > Matthew Gretton-Dann > Toolchain Working Group, Linaro > > ___ > linaro-enterprise mailing list > linaro-enterpr...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-enterprise ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
