Re: Profile guided and string routines?
On 12/17/2010 2:51 AM, Andrew Stubbs wrote: >> * Have the compiler expose an API for recording information about the >> value of arguments to a function when profiling. For integer arguments, >> this might be the minimum, maximum, and average. For pointers, NULL vs. >> non-NULL. Etc. > > Presumably recording the return value of functions would also be handy, > especially in this case? Indeed. >> * Provide a plug-in that allows the user to instrument particular >> functions (e.g., strlen) by providing profiling rules: > > This is cool, but most users want it to Just Work (tm). Is a plugin a > suitable way to implement an on-by-default feature? I think so. The plug-in could always ship with the compiler, just as various Eclips plug-ins ship with Eclipse, or as various kernel modules ship with the kernel. The benefit of a plug-in interface is not just third-party delivery, but also the ability for users to modify and configure behavior. We've traditionally hard-coded things into the compiler to optimize the behavior of built-in functions, but that's something that should (ideally) be under the control of users. For example, a library developer might very well like to ship some Python code that told the compiler that calling f(g(x)) is equivalent to calling h(x), or that if n < 3, you should translate f(n) into g(1); ...; g(n). -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Profile guided and string routines?
On 12/16/2010 3:57 PM, Steven Bosscher wrote: > It looks to me like a case of value profiling, see tree-profile.c, for > the various "stringops" optimizations. Unless I misunderstand David's > idea here or missing something else, it seems that this kind of > optimization should fit in the existing infrastructure without too much > effort. That's good; I hadn't realized that this stuff had all gotten wired up. It does look like there's code in value-prof.c to do some stuff with string operations. If I'm reading the code correctly, gimple_stringops_transform will take a call to (say) memset with an argument that has a given value 80% of the time and inline the call. So, yes, you could put more smarts in there to deal with other things. (Right now, it only does mem* routines, and only deals with the constant argument case.) I'd still like to see this handled a lot more generally, but I'm not saying that we should gate incremental progress on a grand plan. We could do both. :-) -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Dec. 13th -- Dec. 18th
== Linaro GDB == * LP:615972 Different output of 'info register' w/ and wo/ corefile. Understands gcore impl in gdb. Two patches are reviewed in upstreams. One is approved by Dan, and the other is still be reviewed. Evaluate the two approaches for NEON registers in corefile. Resume the discussion on kernel support for dumping NEON registers. Need a decision with kernel side, but no progress on it. * LP:685494 Revise patch per Pedro's suggestion. Waiting for someone to approve it. * LP:685702 Get it approved for FSF GDB 7.2 branch. Committed to both FSF 7.2 branch and Linaro tree. * LP:616003 gdb.mi/mi-var-display.exp failure GDB always assumes $fp is r11, even code is in thumb mode. Current GDB infrastructure can't handle mapping the same alias to two different registers. Proposed a new gdbarch took for this in upstreams, in order to increase the flexibility of GDB. No reply yet. * LP:616001 gdb.mi/mi-var-cmd.exp failure Ulrich pointed out it is caused by stack randomization. Confirmed this by setting "kernel.randomize_va_space" to zero. Figure out why this case passes on x86, because it is more restricted to turn on stack randomization on x86. * LP:615980 Support displaced stepping on Thumb Understands displaced stepping in GDB/ARM. Find a bug when GDB tries to execute ARM instruction in copy area, which is in Thumb mode (copy area starts from "_start + 4", and it is compiled in Thumb mode in Ubuntu). The fix is an one-line patch, which doesn't update status register when writing PC in displaced stepping. Write a test case for arm displaced stepping. Write code in ARM asm directly for the first time, which is very helpful to remember ARM asm instructions. Read ARM ARM and decode 16-bit thumb instructions in GDB for displaced stepping. It doesn't work so far because breakpoint instruction after instructions in copy area is still hard-coded to ARM breakpoint insn. == Misc == * Linaro GCC optimization meeting. == This Week == * LP:615980 Support displaced stepping on Thumb Send my fix and test case to upstreams for review. Make displaced stepping work on 16-bit instruction. * Ping other GDB patches. -- Yao (齐尧) ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Dec.13 -- Dec.19
== GCC related == * CS Issue #10201 / PR46883, unrecognizable insn ICE when compiling Samba. Fixed this by changing the predicates of two split patterns. Patch reviewed in CS internally and upstream, committed upstream, will backport to SG++ and Linaro soon. * LP:641397/PR46888: bitfield insert optimization. Andrew Pinski found a testcase that escapes the CSE patch gets handled by combine, and also found another bug with REG_EQUIV notes. Only looked at this minimally last week, will really work on this later. * LP:687406/PR46865, -save-temps creating different code. Backported and bzr-pushed the upstream fix by Jakub Jelinek. * PR45416, ARM code regression. Mostly can generate what I wanted by now, under ARM and x86, although patch is still not in a submittable state. * VFP index patch. Uncommitted GCC patch of mine from last year; added Thumb-2 bits and corrected some things in the testcase. Committed upstream. == This week == * Really get January travel stuff nailed. * Upstream patch review is probably going to start getting slow/suspended this week. Will probably do some study stuff on larger projects. * Continue to look at GCC issues. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
