Set inline-unit-growth to 40

Christophe Lyon christophe.lyon@linaro.org
Thu Jan 17 13:22:00 GMT 2019


On Mon, 14 Jan 2019 at 17:40, Jan Hubicka <hubicka@ucw.cz> wrote:
>
> Hello,
> > > Index: params.def
> > > ===================================================================
> > > --- params.def  (revision 267882)
> > > +++ params.def  (working copy)
> > > @@ -227,7 +227,7 @@ DEFPARAM(PARAM_LARGE_UNIT_INSNS,
> > >  DEFPARAM(PARAM_INLINE_UNIT_GROWTH,
> > >          "inline-unit-growth",
> > >          "How much can given compilation unit grow because of the inlining (in percent).",
> > > -        20, 0, 0)
> > > +        40, 0, 0)
> > >  DEFPARAM(PARAM_IPCP_UNIT_GROWTH,
> > >          "ipcp-unit-growth",
> > >          "How much can given compilation unit grow because of the interprocedural constant propagation (in percent).",
> >
> > This patch introduces a regression in libstdc++:
> > FAIL: ext/pb_ds/regression/list_update_map_rand.cc execution test
> > on a few arm targets.
> >
> > For instance:
> > arm-none-linux-gnueabihf
> > --with-mode arm
> > --with-cpu cortex-a5
> > --with-fpu vfpv3-d16-fp16
>
> Adjusting inliner heuiristics should not trigger correcness issues, so
> this seems like a bug that was previously latent.  I guess it may
> legally break correct code only if stack usage gets too large.
>

Indeed I didn't expect such a change to involve correctness issues.


> Do you have any idea what breaks in this testcase?
>

Hmm, I've just seen this test fail then pass again in validations
that did not involve any change related to it.
So there's some "randomness", and the logs are not very helpful
(no message saying memory exhaustion or similar)


> Honza
> >
> > Using --with-mode thumb and the same other configure options makes the
> > test pass.
> > I'm seeing this with other configurations --with-mode arm and
> > --with-fpu vfp* (as opposed to neon*)
> >
> > The .log file has:
> > <?xml version = "1.0"?>
> > <test>
> > <sd value = "1547347280">
> > </sd>
> > <n value = "50">
> > </n>
> > <m value = "10">
> > </m>
> > <tp value = "0.2">
> > </tp>
> > <ip value = "0.6">
> > </ip>
> > <ep value = "0.2">
> > </ep>
> > <cp value = "0.001">
> > </cp>
> > <mp value = "0.25">
> > </mp>
> > </test>
> > <cntnr name = "lu_mtf_map">
> > <desc>
> > <type value = "list_update">
> > <Update_Policy value = "lu_move_to_front_policy">
> > </Update_Policy>
> > </type>
> > </desc>
> > <progress>
> > ----------------------------------------
> > ************qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> >
> > The (incomplete?) qemu execution trace ends with:
> > ----------------
> > IN:
> > 0x40ada6b8:  e5910008  ldr      r0, [r1, #8]
> > 0x40ada6bc:  e1560000  cmp      r6, r0
> > 0x40ada6c0:  1a00004f  bne      #0x40ada804
> > ----------------
> > IN:
> > 0x40ada6c4:  e5960004  ldr      r0, [r6, #4]
> > 0x40ada6c8:  e582100c  str      r1, [r2, #0xc]
> > 0x40ada6cc:  e3500c02  cmp      r0, #0x200
> > 0x40ada6d0:  e5812008  str      r2, [r1, #8]
> > 0x40ada6d4:  3a000002  blo      #0x40ada6e4
> > ----------------
> > IN:
> > 0x40adb880:  eaffff3e  b        #0x40adb580
> > ----------------
> > IN: _ZN10__gnu_pbds4test6detail30container_rand_regression_testINS_11list_updateINS0_10basic_typeES4_St8equal_toIS4_ENS0_26lu_move_to_front_policy_t_EN9__gnu_cxx22throw_allocator_randomIS4_EEEEE13subscript_impENSt3tr117integral_constantIiLi0EEE
> > 0x0001ffc4:  e3a06000  mov      r6, #0
> > 0x0001ffc8:  eaffff88  b        #0x1fdf0
> > ----------------
> > IN: _ZN10__gnu_pbds4test6detail30container_rand_regression_testINS_11list_updateINS0_10basic_typeES4_St8equal_toIS4_ENS0_26lu_move_to_front_policy_t_EN9__gnu_cxx22throw_allocator_randomIS4_EEEEE13subscript_impENSt3tr117integral_constantIiLi0EEE
> > 0x0001fdf0:  ee180a10  vmov     r0, s16
> > 0x0001fdf4:  ebffcd12  bl       #0x13244
> >
> > Christophe



More information about the Gcc-patches mailing list