From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2121.outbound.protection.outlook.com [40.107.21.121]) by sourceware.org (Postfix) with ESMTPS id D76A73881D26 for ; Fri, 16 Dec 2022 11:37:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D76A73881D26 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=Syrmia.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Syrmia.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZbCumhB+DqrxCz96NtxjR6zR30BpcXlbyYXejZHJ1hA1DlVSiSonCZO39BawTLANoXugc/v3Gv+74v64+VsEntA5hwfHsi6kbiOA0W5YbeHhBKQ3XDFHxYHuuwr6iYrkp0n8utAignY7mx6IgozbF60Lbr/hkp0SxTEKd6u+5PFrux4BqfrqGMZwCTWdx6YTSmfkp+h1GNnGwoILBliEJ7J+qaqpv1vIKzVm7BUbWUDYdCrwAkQcE4aLVbkFDi1zR22792eNLJIS/1Iyh00GUZPLimd/7G6AZoHZSqDQbWe8AdBObIFygFi7gE+aE6J2r2xpXrfK2DxoogmZ8rQruw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XhbIw9kOofeQUfQv++QYX0L5k2Zu3hHK22d7F3dvThI=; b=Y3vtUsIj3jJ80/mhSkEyyeQG2j11ZUVrfpinXRjWc/9Yjgf82nthJjOukSIQ2VsB6HcgcsHEY2SDv0nErYE1Y6/pIU+jhrPX5ubYyoCcVvReMnZox6thphXT6f7DxhVCa7UgZbh6msSrP+sjda7MBUW6Oq+Hhx5r2ddH23v+KoxZwTrKGtgy8fAdfCMI1Qg0nXVzWi11fHXFTJingMhkkpS0HCCri3Wdgx6Bezqtt4gZNE9Bi16Q5I11dme97yjjbjlOAEjSUgVTzyd+aVjSSd1OJ2IiarsH2yi6sMr9c0tgWNvfTgObkJRcImzMOL5PpacvVN+mD6CofkGV+dFP/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=syrmia.com; dmarc=pass action=none header.from=syrmia.com; dkim=pass header.d=syrmia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=syrmia.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XhbIw9kOofeQUfQv++QYX0L5k2Zu3hHK22d7F3dvThI=; b=nMxPlIEMBbKOyqQqTeRoGorcTydVpjQDRya2IICjv4dNKCJM9VAM5Q7wPZwocFpqB/A12zvMB4SOUNaYb1C3pXwBiyAasljCdZebw4cRzApTJeS6yc0/cOTI1MIozS2HQB9IMpyktVDJ4vMLSR2doo6FSoGGbYTiHv+f/6kXk5I= Received: from AM0PR03MB4882.eurprd03.prod.outlook.com (2603:10a6:208:fb::17) by DB9PR03MB7436.eurprd03.prod.outlook.com (2603:10a6:10:223::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.11; Fri, 16 Dec 2022 11:37:43 +0000 Received: from AM0PR03MB4882.eurprd03.prod.outlook.com ([fe80::6d55:c3be:1328:429b]) by AM0PR03MB4882.eurprd03.prod.outlook.com ([fe80::6d55:c3be:1328:429b%7]) with mapi id 15.20.5880.019; Fri, 16 Dec 2022 11:37:43 +0000 From: Dimitrije Milosevic To: Richard Biener CC: Jeff Law , "gcc-patches@gcc.gnu.org" , Djordje Todorovic Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity. Thread-Topic: [PATCH 1/2] ivopts: Revert computation of address cost complexity. Thread-Index: AQHY5VSpCkpNZ9wRE0qr2B1vutRVJa4i5Z0AgAB9V4aAAAhsgIAHDpgAgADoiyKACC5rgIA70MbWgAE9jICAABbTAQ== Date: Fri, 16 Dec 2022 11:37:43 +0000 Message-ID: References: <20221021135203.626255-1-dimitrije.milosevic@syrmia.com> <20221021135203.626255-2-dimitrije.milosevic@syrmia.com> <3c50de1f-c00b-9f8a-a604-a71bc546f1c2@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=Syrmia.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AM0PR03MB4882:EE_|DB9PR03MB7436:EE_ x-ms-office365-filtering-correlation-id: 01ed2d3b-c7ba-4c3c-35f7-08dadf59f21f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b9u3c/UMm5vNfDbzZqbnSkTqScUje/gdcSiNAVFS5F1YRs+LT/tkdsSWAl/iw8dMXcMmvXFTE7n/BYVmG32FpC5bo4dctJwlkKprpPPiii7Z6CcrJsNJthNRu18oxVkM4PbNH6D49WWmC0Qt+QcM0Mt1r7xIBWet6i0XHAZw9qU04i2VmCeeB/5jJTOuunUXfeULS+GAlPQsjhMSeHhsk66uBsYseXnOho1+iwhPaBZD7CEoFRdrCh6nbnT0Z0av/vf7nbvKpBMjfW8KEiM/MvwJNoloKB9N9PvVwsDiin0FrZzVrZAFKjnsyIsTMngD9vbJeGIxH/CHkarJN3PWKcP0gKYwW0QqUCZmDxyTN/Rpbw8k2hEOLjPoij1c3GkA616DNqPN58QGtJRJMeqyTtBwiphYDXq+FaV5L6wZ+lLGqfpOu+Lb4k3RW1aB6OlDewzO5wu3yh7OhxcB3W9Ugm/VHbDcrcU39JdarsHjzGLZU64JTNqBWl80N/+jLSJ7jjfbl6TASyvbrtm1VA9GoUTs+C1GmAsxApzR1S14+gbLkSzAmjXQjGEDLy2/5gQTMoty4Rr34wp+nMzXfMNTzOpy4TKSSDMoD/uGPA+9knyAGD3omdQflXmwCpfv1vaA5GhYu3BSTpJEiZc8cr+0BsyniM3vixB6UKMezccAZOeFfbMi0/hMTmEXEoNhLJZn/RguL/05YHJHHQIh4JCS6Q== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR03MB4882.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(376002)(136003)(346002)(366004)(396003)(39830400003)(451199015)(33656002)(4326008)(38070700005)(6916009)(66476007)(316002)(54906003)(64756008)(86362001)(41300700001)(66946007)(8676002)(91956017)(66446008)(76116006)(66556008)(83380400001)(38100700002)(122000001)(55016003)(71200400001)(7696005)(107886003)(6506007)(8936002)(5660300002)(52536014)(2906002)(26005)(478600001)(9686003)(186003)(53546011);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?r5+ziy7fqS6VKa8I0HbFpEAkfPIKuY3TKokKP1g6bIvFQmWAhTaiw5jKaf?= =?iso-8859-1?Q?eixnK1omyc9wCTpcZ2x8adpJHZ4B+jioOV0bjGfaP6kwagOH3hvmTlgKVD?= =?iso-8859-1?Q?PRDMmACpWgRYJOhE98gXBq74BLjsxCrjatl0d1iZNtD78sfjSUpd4FhfB8?= =?iso-8859-1?Q?5CDbVy1EiZW+rnVeCklxRvaj6VBVfk9TuGF+KjGOFnP834feUfEgkjhgWm?= =?iso-8859-1?Q?fXfuUtZpLOqToUYAODnqploOHav3ZetVblrvwTY3pwAEqmvkYxU5y8tJKs?= =?iso-8859-1?Q?ZEI0jqQb8NFxsPhPcqFmopalHVYd0sstEMDKkgG3H8x8y44OL0WQ02FTDb?= =?iso-8859-1?Q?m7N9a5v95qlUyY17KXFJmZ2SiWzaOWqsSoQENMNSfiHCixL975zvqr0rYo?= =?iso-8859-1?Q?Ht63pwZIwR9FHcjXtwopVEwvJVRJu+67QaEZBEO7wKag35QEE8BbzBn4N4?= =?iso-8859-1?Q?EFihr/kswA5pKUeVi5t/MapLVwUbN00nHs2KYiDOL+pVvAQvbURbIGPx3y?= =?iso-8859-1?Q?liVOR6HifRzJmQQWo6TEcz0V9CJuFUNswWWOZ5Kk99/bWKqJB07+9WNT0W?= =?iso-8859-1?Q?vNrrttXatiu0I4bMXT6f42n/q+sB+A/FIFZgcb3wmTE0/+cCCibBQ6eSOw?= =?iso-8859-1?Q?rWMST7klFPjYFuZwodzhQcNMJ4ZG5zZGOEOCG9QqXk9MA6BfopQnp+5Eze?= =?iso-8859-1?Q?RxtmR6xTEyVW9V1ewJ1kMyBnP4Xyl+32doqb8fSXmvlGN8vaJQwQiqXVuO?= =?iso-8859-1?Q?0G+3oQOD5fGJ3wQo8LQ4bWnEuXQiW48o5GVohjrtnvm3TEL+oaPSF8iVlm?= =?iso-8859-1?Q?Ca+mzP51sA7koI3ecG5MGWHU6O4OXtL7xkdP7R42Rhml17TwzmH1tLhZ3o?= =?iso-8859-1?Q?XmQZ/rjQUpF/1v39iIRSEph+SDuFKlnYtvgeOEX8cPrqB47v5+tHCHzSj6?= =?iso-8859-1?Q?92d6alip9zVKcCvxm9JV3M8rpzwLnBlmzvGhZ2OphNwk+Xu11pOZFTTkx3?= =?iso-8859-1?Q?G4+XlCXI/67/zyARQ7qUOmAoW/IszFiucNOId7Ygotq3NTMovSJD3Yt2NF?= =?iso-8859-1?Q?Pf/cpokUjR6rhFfvisBLValHXeG9NP3r2CdHgh/sZjgQro1RW/OWRWxylL?= =?iso-8859-1?Q?extWM639qQ9gpgm+DpFjw2mMhsMbvEpd0RvFo0hkJn7AeP96yQEamNoVz+?= =?iso-8859-1?Q?LjvwmApGwQF/rFjsMrVw5HXmV2SWnEbL/bRdUUpie6SaI3xQJb1PYwVeHr?= =?iso-8859-1?Q?3F7mShcjbK+pl9nMtrIuvHKwi3t7s5nQ9+HYPtEUuGZVpLcKjhd95T64mf?= =?iso-8859-1?Q?fv3qXBcrhVrau2spRFKBr/HshpNUZ+/c5ba5xCl3wFxuZe7FbPZER2O35W?= =?iso-8859-1?Q?+VfpD+uAwNTa160tLVoybSgVxJXi5qT4SQk6qy/8/cValC3fELItj+/6hx?= =?iso-8859-1?Q?+G7EdJClktihc0Mx+P29eKfcIPdgej20QJlGD2yDKJN5ru/TpPwkER88G+?= =?iso-8859-1?Q?nm+9FdhutMyjamyQ+uT9FXsCXpGBooO2pNw/H85Zjg6nO1xneN1wQw9LcC?= =?iso-8859-1?Q?ciQN8B0GVtRZenxMmX6+v+AhZQ9aC0Xq7k78mYqYLrst9yOkL4jDsBSee8?= =?iso-8859-1?Q?m65JkOr+MLPie+qd4YbGZoxybdsQihBo5y4YXqAzh1H64AoPi2ZO+WqQ?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: syrmia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4882.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01ed2d3b-c7ba-4c3c-35f7-08dadf59f21f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2022 11:37:43.3092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 19214a73-c1ab-4e19-8f59-14bdcb09a66e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gadRaw1FI4LGoCC4Z+rmH1uXnEIJDEnXpq3rX1btEGMHKaCtYVA2rcpJmo5gFzFeNWHINaVSrHSOdrPJTyedrS7Zmp3aLg8/SHLkbilZNqY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7436 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: =0A= Hi Richard,=0A= =0A= > The only documentation on complexity I find is=0A= >=0A= > =A0 int64_t cost;=A0=A0=A0=A0=A0=A0=A0=A0 /* The runtime cost.=A0 */=0A= > =A0 unsigned complexity;=A0 /* The estimate of the complexity of the code= for=0A= > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 the computation (in no concrete units --=0A= > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 complexity field should be larger for more=0A= > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 complex expressions and addressing modes).=A0 */=0A= >=0A= > and complexity is used as tie-breaker only when cost is equal.=A0 Given t= hat=0A= > shouldn't unsupported addressing modes have higher complexity?=A0 I'll no= te=0A= > that there's nothing "unsupported", each "unsupported" address computatio= n=0A= > is lowered into supported pieces.=A0 "unsupported" maybe means that=0A= > "cost" isn't fully covered by address-cost and compensation stmts might= =0A= > be costed in quantities not fully compatible with that?=0A= =0A= Correct, that's what I was aiming for initially - before f9f69dd that was t= he case,=0A= "unsupported" addressing modes had higher complexities.=0A= Also, that's what I meant by "unsupported" as well, thanks.=0A= =0A= > That said, "complexity" seems to only complicate things :/=A0 We do have = the=0A= > tie-breaker on preferring less IVs.=A0 complexity was added in=0A= > r0-85562-g6e8c65f6621fb0 as part of fixing PR34711.=0A= =0A= I agree that the complexity part is just (kind of) out there, not really st= rongly=0A= defined. I'm not sure how to feel about merging complexity into the cost pa= rt=0A= of an address cost, though.=0A= =0A= > If it's really only about the "complexity" value then each=0A= > compensation step should=0A= > add to the complexity?=0A= =0A= That could be the way to go. Also worth verifying is that we compensate for= =0A= each case of an unsupported addressing mode.=0A= =0A= Kind regards,=0A= Dimitrije=0A= =0A= From: Richard Biener =0A= Sent: Friday, December 16, 2022 10:58 AM=0A= To: Dimitrije Milosevic =0A= Cc: Jeff Law ; gcc-patches@gcc.gnu.org ; Djordje Todorovic =0A= Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complex= ity. =0A= =A0=0A= On Thu, Dec 15, 2022 at 4:26 PM Dimitrije Milosevic=0A= wrote:=0A= >=0A= > Hi Richard,=0A= >=0A= > Sorry for the delayed response, I couldn't find the time to fully focus o= n this topic.=0A= >=0A= > > I'm not sure this is accurate but at least the cost of using an unsuppo= rted=0A= > > addressing mode should be at least that of the compensating code to=0A= > > mangle it to a supported form.=0A= >=0A= > I'm pretty sure IVOPTS does not filter out candidates which aren't suppor= ted by=0A= > the target architecture. It does, however, adjust the cost for a subset o= f those.=0A= > The adjustment code modifies only the cost part of the address cost (whic= h=0A= > consists of a cost and a complexity).=0A= > Having said this, I'd propose two approaches:=0A= >=A0=A0=A0=A0 1. Cover all cases of unsupported addressing modes (if needed= , I'm not entirely=0A= >=A0=A0=A0=A0=A0=A0=A0=A0 sure they aren't already covered), leaving comple= xity for unsupported=0A= >=A0=A0=A0=A0=A0=A0=A0=A0 addressing modes zero.=0A= =0A= The only documentation on complexity I find is=0A= =0A= =A0 int64_t cost;=A0=A0=A0=A0=A0=A0=A0=A0 /* The runtime cost.=A0 */=0A= =A0 unsigned complexity;=A0 /* The estimate of the complexity of the code f= or=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 the computation (in no concrete units --=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 complexity field should be larger for more=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 complex expressions and addressing modes).=A0 */=0A= =0A= and complexity is used as tie-breaker only when cost is equal.=A0 Given tha= t=0A= shouldn't unsupported addressing modes have higher complexity?=A0 I'll note= =0A= that there's nothing "unsupported", each "unsupported" address computation= =0A= is lowered into supported pieces.=A0 "unsupported" maybe means that=0A= "cost" isn't fully covered by address-cost and compensation stmts might=0A= be costed in quantities not fully compatible with that?=0A= =0A= That said, "complexity" seems to only complicate things :/=A0 We do have th= e=0A= tie-breaker on prefering less IVs.=A0 complexity was added in=0A= r0-85562-g6e8c65f6621fb0 as part of fixing PR34711.=0A= =0A= >=A0=A0=A0=A0 2. Revert the complexity calculation (which my initial patch = does), leaving=0A= >=A0=A0=A0=A0=A0=A0=A0=A0 everything else as it is.=0A= >=A0=A0=A0=A0 3. A combination of both - if the control path gets into the = adjustment code, we=0A= >=A0=A0=A0=A0=A0=A0=A0=A0 use the reverted complexity calculation.=0A= =0A= If it's really only about the "complexity" value then each=0A= compensation step should=0A= add to the complexity?=0A= =0A= > I'd love to get feedback regarding this, so I could focus on a concrete a= pproach.=0A= >=0A= > Kind regards,=0A= > Dimitrije=0A= >=0A= > From: Richard Biener =0A= > Sent: Monday, November 7, 2022 2:35 PM=0A= > To: Dimitrije Milosevic =0A= > Cc: Jeff Law ; gcc-patches@gcc.gnu.org ; Djordje Todorovic =0A= > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost compl= exity.=0A= >=0A= > On Wed, Nov 2, 2022 at 9:40 AM Dimitrije Milosevic=0A= > wrote:=0A= > >=0A= > > Hi Jeff,=0A= > >=0A= > > > This is exactly what I was trying to get to.=A0=A0 If the addressing = mode=0A= > > > isn't supported, then we shouldn't be picking it as a candidate.=A0 I= f it=0A= > > > is, then we've probably got a problem somewhere else in this code and= =0A= > > > this patch is likely papering over it.=0A= >=0A= > I'm not sure this is accurate but at least the cost of using an unsupport= ed=0A= > addressing mode should be at least that of the compensating code to=0A= > mangle it to a supported form.=0A= >=0A= > > I'll take a deeper look into the candidate selection algorithm then. Wi= ll=0A= > > get back to you.=0A= >=0A= > Thanks - as said the unfortunate situation is that both the original auth= or and=0A= > the one who did the last bigger reworks of the code are gone.=0A= >=0A= > Richard.=0A= >=0A= > > Regards,=0A= > > Dimitrije=0A= > >=0A= > > ________________________________________=0A= > > From: Jeff Law =0A= > > Sent: Tuesday, November 1, 2022 7:46 PM=0A= > > To: Richard Biener; Dimitrije Milosevic=0A= > > Cc: gcc-patches@gcc.gnu.org; Djordje Todorovic=0A= > > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost com= plexity.=0A= > >=0A= > >=0A= > > On 10/28/22 01:00, Richard Biener wrote:=0A= > > > On Fri, Oct 28, 2022 at 8:43 AM Dimitrije Milosevic=0A= > > > wrote:=0A= > > >> Hi Jeff,=0A= > > >>=0A= > > >>> THe part I don't understand is, if you only have BASE+OFF, why does= =0A= > > >>> preventing the calculation of more complex addressing modes matter?= =A0 ie,=0A= > > >>> what's the point of computing the cost of something like base + off= +=0A= > > >>> scaled index when the target can't utilize it?=0A= > > >> Well, the complexities of all addressing modes other than BASE + OFF= SET are=0A= > > >> equal to 0. For targets like Mips, which only has BASE + OFFSET, it = would still=0A= > > >> be more complex to use a candidate with BASE + INDEX << SCALE + OFFS= ET=0A= > > >> than a candidate with BASE + INDEX, for example, as it has to compen= sate=0A= > > >> the lack of other addressing modes somehow. If complexities for both= of=0A= > > >> those are equal to 0, in cases where complexities decide which candi= date is=0A= > > >> to be chosen, a more complex candidate may be picked.=0A= > > > But something is wrong then - it shouldn't ever pick a candidate with= =0A= > > > an addressing=0A= > > > mode that isn't supported?=A0 So you say that the cost of expressing= =0A= > > > 'BASE + INDEX << SCALE + OFFSET' as 'BASE + OFFSET' is not computed= =0A= > > > accurately?=0A= > >=0A= > > This is exactly what I was trying to get to.=A0=A0 If the addressing mo= de=0A= > > isn't supported, then we shouldn't be picking it as a candidate.=A0 If = it=0A= > > is, then we've probably got a problem somewhere else in this code and= =0A= > > this patch is likely papering over it.=0A= > >=0A= > >=0A= > > Jeff=0A= > >=