Can we undo the octeon hack?
Juli Mallett
juli at clockworksquid.com
Mon Jul 22 03:27:24 UTC 2013
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
More information about the freebsd-mips
mailing list