Can we undo the octeon hack?

[Warner Losh]

On Jul 21, 2013, at 9:00 PM, Juli Mallett wrote:
> I know I shouldn't say this, but: How hard can it be? :P

How hard do you want it to be?

> In kern.pre.mk:
> 
> CFLAGS_PARAM_INLINE_UNIT_GROWTH?=100
> CFLAGS_PARAM_LARGE_FUNCTION_GROWTH?=1000
> CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE?=/* XXX what is default? */
> CFLAGS+= --param inline-unit-growth=${CFLAGS_PARAM_INLINE_UNIT_GROWTH}
> CFLAGS+= --param large-function-growth=${CFLAGS_PARAM_LARGE_FUNCTION_GROWTH}
> CFLAGS+= --param max-inline-insns-single=${CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE}
> 
> And then in the Octeon config:
> 
> makeoptions CFLAGS_PARAM_INLINE_UNIT_GROWTH=10000
> makeoptions CFLAGS_PARAM_LARGE_FUNCTION_GROWTH=100000
> makeoptions CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE=10000
> 
> Right?

Other than being completely wrong, this looks good... :)

> Come up with a better name scheme, win 1/20 of 1 US cent.  (Not
> redeemable for cash.)
> 
> Most users will never see it; only Octeon needs such behaviour because
> of how the Simple Executive is implemented.

Except we'd need it in every octeon config file :(

Warner

> On Sun, Jul 21, 2013 at 7:56 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>> .... ok, so, what's the game plan? :)
>> 
>> 
>> 
>> -adrian
>> 
>> On 21 July 2013 18:47, Juli Mallett <juli at clockworksquid.com> wrote:
>>> Do you think we should gate moving this singular hack to the Octeon
>>> config file on breaking out a bunch of std.foo files now? :)  I was
>>> just saying that if you're advocating doing that work, we should do
>>> some more generalized stuff, too.  Like, std.pcidriversandwhatnot
>>> should be machine-independent and would reduce a lot of maintenance
>>> between architectures, that kind of thing.  I don't think any of it
>>> should gate moving INLINE_CFLAG_SOMETHING_FOO_WHATEVER_BISCUIT_* into
>>> the Octeon kernel config and out of sys/conf.
>>> 
>>> On Sun, Jul 21, 2013 at 6:34 PM, Warner Losh <imp at bsdimp.com> wrote:
>>>> I would too, but let's not gate a solution to this problem on that.
>>>> 
>>>> Warner
>>>> 
>>>> On Jul 21, 2013, at 3:29 PM, Juli Mallett wrote:
>>>> 
>>>>> I would really like a std.pci or something, too, so we don't have to
>>>>> enumerate all the PCI devices in every config.
>>>>> 
>>>>> On Sun, Jul 21, 2013 at 1:51 PM, Warner Losh <imp at bsdimp.com> wrote:
>>>>>> These should really be in the std.foo files for each specific subport. That way atheros could have one set, and octeon could have another.
>>>>>> 
>>>>>> I do know that we don't do the std.foo thing for the atheros config files, but we really should start, and this would be a good place to start...
>>>>>> 
>>>>>> Warner
>>>>>> 
>>>>>> On Jul 21, 2013, at 12:54 PM, Juli Mallett wrote:
>>>>>> 
>>>>>>> Making it possible to override each value would be ideal but
>>>>>>> cumbersome.  If you want to do that, by all means do!
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Juli.
>>>>>>> 
>>>>>>> On 2013-07-21, at 11:44, Adrian Chadd <adrian at freebsd.org> wrote:
>>>>>>> 
>>>>>>>> Hi Juli/Warner,
>>>>>>>> 
>>>>>>>> Is it possible to undo this particular hack, and allow these values to
>>>>>>>> be overridden in the kernel config files?
>>>>>>>> 
>>>>>>>> from kern.pre.mk
>>>>>>>> 
>>>>>>>> CFLAGS= ${COPTFLAGS} ${C_DIALECT} ${DEBUG} ${CWARNFLAGS}
>>>>>>>> CFLAGS+= ${INCLUDES} -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
>>>>>>>> opt_global.h
>>>>>>>> .if ${COMPILER_TYPE} != "clang"
>>>>>>>> CFLAGS+= -fno-common -finline-limit=${INLINE_LIMIT}
>>>>>>>> .if ${MACHINE_CPUARCH} != "mips"
>>>>>>>> CFLAGS+= --param inline-unit-growth=100
>>>>>>>> CFLAGS+= --param large-function-growth=1000
>>>>>>>> .else
>>>>>>>> # XXX Actually a gross hack just for Octeon because of the Simple Executive.
>>>>>>>> CFLAGS+= --param inline-unit-growth=10000
>>>>>>>> CFLAGS+= --param large-function-growth=100000
>>>>>>>> CFLAGS+= --param max-inline-insns-single=10000
>>>>>>>> .endif
>>>>>>>> .endif
>>>>>>>> 
>>>>>>>> I'd like to be able to experiment with different inline settings in
>>>>>>>> order to try and squeeze kernels down to be smaller.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -adrian
>>>>>> 
>>>>