On 25/03/16 08:02, Charles Baylis wrote: > When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc > function are not generated as long calls. > > This is the sequel to this patch > https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00881.html > > This patch fixes the following problems with the previous patch. > . Nested functions now work (thanks to Richard E for spotting this) > . Thumb-1 now works > > This patch works by adding new patterns (one for ARM/Thumb-2 and one > for Thumb-1) which are placed in the prologue as a placeholder for > some RTL which describes the address. This is either a SYMBOL_REF for > targets with MOVW/MOVT, or a literal pool reference for other targets. > The implementation of ARM_FUNCTION_PROFILER is changed to search for > this insn so that the the address of the __gnu_mcount_nc function can > be loaded using an appropriate sequence for the target. > > I also tried generating the profiling call sequence directly in the > prologue, but this requires some unpleasant hacks to prevent spurious > register pushes from ASM_OUTPUT_REG_PUSH. > > Tested with no new regressions on arm-unknown-linux-gnueabihf on QEMU. > The generated code sequences have been inspected for normal and nested > functions on ARM v6, ARM v7, Thumb-1, and Thumb-2 targets. > > This does not fix a regression, so I don't expect to apply it for > GCC6, is it OK for when stage 1 re-opens. >
Hi Charles, +static void +arm_emit_long_call_profile_insn () +{ + rtx sym_ref = gen_rtx_SYMBOL_REF (Pmode, "__gnu_mcount_nc"); + /* if movt/movw are not available, use a constant pool */ + if (!arm_arch_thumb2) Should this be !TARGET_USE_MOVT? Thanks, Kugan