From owner-freebsd-mips@FreeBSD.ORG Mon Jul 22 03:27:29 2013 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AD934A0 for ; Mon, 22 Jul 2013 03:27:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 07C301FDE for ; Mon, 22 Jul 2013 03:27:28 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id 9so14076326iec.19 for ; Sun, 21 Jul 2013 20:27:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=GXnMAHU4jiHL9fMj3IPxv8OqqKTpQeZoQ6iXIuUDZUY=; b=CnrIYIgMtbyJNRRMt6Ap0o094kZ5dlybN3LOvcrREtHtV31yGJ7dSh3lCVqnqNaPoq N/gLFjg11BGQCvBp055TNy565xO4VHoz4zwzS1VdMr/+AiYvhw8pD1pYJ5NRwJUx/Zok a2U/Ri8KWcYyYnDy4/bLouZQ0r8w3mNwe1B7bgIQNcC3bGCpOQKi0/nmQYdTkhwn3cLD PbhIxClkRAJrN9sMP0aQ/2S8izbSqqjQ8FD1a4l0Nih8WfT3TW3xOabJSOaO1RvJ7JvQ 8+pLcRhPZqxL54ReoKML0VTKKlszdsvhxoSCO8XH26nq0YWXzQFMZPEhRK9q9tt2NnlP 2ZLA== X-Received: by 10.43.141.206 with SMTP id jf14mr16638649icc.8.1374463648180; Sun, 21 Jul 2013 20:27:28 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id w5sm54699185igz.10.2013.07.21.20.27.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 20:27:27 -0700 (PDT) Sender: Warner Losh Subject: Re: Can we undo the octeon hack? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 21 Jul 2013 21:27:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <83EA6D99-9B5F-400A-BC79-BE4D16255A84@bsdimp.com> References: <6401792509903023722@unknownmsgid> <8C6BE511-2CCD-434F-BE72-43F350E8AA2C@bsdimp.com> <793CB840-40AF-487E-99A0-2C34FF17FD11@bsdimp.com> To: Juli Mallett X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnD6Jx9Ng0OsqzJHt09Su3sw8KhakecxZp4/IKQZ4Idwya+ZSg1SAB94KwlMU7J4btF0xHp Cc: Warner Losh , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:27:29 -0000 On Jul 21, 2013, at 9:18 PM, Juli Mallett wrote: > On Sun, Jul 21, 2013 at 8:12 PM, Warner Losh wrote: >>=20 >> 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 >>=20 >> How hard do you want it to be? >>=20 >>> In kern.pre.mk: >>>=20 >>> CFLAGS_PARAM_INLINE_UNIT_GROWTH?=3D100 >>> CFLAGS_PARAM_LARGE_FUNCTION_GROWTH?=3D1000 >>> CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE?=3D/* XXX what is default? */ >>> CFLAGS+=3D --param = inline-unit-growth=3D${CFLAGS_PARAM_INLINE_UNIT_GROWTH} >>> CFLAGS+=3D --param = large-function-growth=3D${CFLAGS_PARAM_LARGE_FUNCTION_GROWTH} >>> CFLAGS+=3D --param = max-inline-insns-single=3D${CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE} >>>=20 >>> And then in the Octeon config: >>>=20 >>> makeoptions CFLAGS_PARAM_INLINE_UNIT_GROWTH=3D10000 >>> makeoptions CFLAGS_PARAM_LARGE_FUNCTION_GROWTH=3D100000 >>> makeoptions CFLAGS_PARAM_MAX_INLINE_INSNS_SINGLE=3D10000 >>>=20 >>> Right? >>=20 >> Other than being completely wrong, this looks good... :) >>=20 >>> Come up with a better name scheme, win 1/20 of 1 US cent. (Not >>> redeemable for cash.) >>>=20 >>> Most users will never see it; only Octeon needs such behaviour = because >>> of how the Simple Executive is implemented. >>=20 >> Except we'd need it in every octeon config file :( >=20 > 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=