Can we undo the octeon hack?

[Warner Losh]

On Jul 21, 2013, at 9:18 PM, Juli Mallett wrote:

> On Sun, Jul 21, 2013 at 8:12 PM, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> 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 :(
> 
> We have a lot of stuff we need in every Octeon config file already, I
> don't see this as making that worse.  std.octeon or whatever it's
> called would be fine, too.  I just don't care for the NetBSD-ish std.*
> system and don't make much use of it myself, but it seems reasonable
> to put it there, since one already exists.  Oh, wait, that's misnamed
> "std.octeon1" so let's refuse to do anything about that, too? :P

I used to hate the std.foo stuff, but after putting nearly all the SoC specific glue for dozens of different SoCs over on the ARM side in them, I began to see its wisdom...

Warner