From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2DB143858C78 for ; Wed, 6 Sep 2023 19:43:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DB143858C78 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694029408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+lg+MgUdl5HaqTTwEr41rZZ/7pFDKfOE1G8C9zHn6UY=; b=VLqQWF85v8t2CRNQx8sWlNN5yumax243CDxrdHF+r0cjGCiC3MjaTc/dxRGv3G9ojyJ+6C a0Bh4u97nWfPzH/VvQFv1KQloT8xSy3k6mkdiGm0Gf7FA7/iJ9wehTYz2Frs9ZxuhLq3ra ufyqQyLbIeRgrKkOOEE60h9rTTrwfNM= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-662-LPKFS9xaMy6DC_G9JwEjqQ-1; Wed, 06 Sep 2023 15:43:26 -0400 X-MC-Unique: LPKFS9xaMy6DC_G9JwEjqQ-1 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-64f412e568eso2292686d6.0 for ; Wed, 06 Sep 2023 12:43:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694029406; x=1694634206; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+lg+MgUdl5HaqTTwEr41rZZ/7pFDKfOE1G8C9zHn6UY=; b=B3PXLoxFDkqPX7OEeUPZwqbCTIfqFJpUbvgSMyfEJO1lMx6fDRbghzu/ee0XRUueaj iBABdlsYBiBuljtCnMSvQa4tP9n3z9TOfYET11ka1hs5GABdqejwPAnAa/sFW51458DA mv8Ne54CG6AerW6hmsqyp+3lTqWP6f12f+NGR3MPToSqHQaJuscMpJJeB2vG+r0yBrRT szWp2I6zCB8IjtCaC5cyAvMPfZGTy4OIbAY7S0ESJ/nbUSnMxCulJNlNJMxB4TnuA3Yt 6xDp3U92kKXeezuCJrKjhviklRdShBrbgG8yJSzK+SgnW7WGG7rnxRoMZty9pgEbSOCn ppiA== X-Gm-Message-State: AOJu0YzUlCVifE7YzKK4yzEACFE87upMUmhQn10vGIqm+WkGisUbrsN3 tL+nvmwl2JZvRXA0PBwjdEAY9pwD/Y4fWuxvz3Uvfg6JnmxpIp5PSXRa97ermi32QUOZezt6lHz 877G4sgTBbS2ttuR73A== X-Received: by 2002:a0c:b452:0:b0:651:69d7:3d6a with SMTP id e18-20020a0cb452000000b0065169d73d6amr16259910qvf.15.1694029406042; Wed, 06 Sep 2023 12:43:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGVBt/I4bl86R+VW1QzbKVewGXcAdTHVPrvo9P7unzZZ7HsnL0JyPQL21AL1/+QNv/bgXxXuw== X-Received: by 2002:a0c:b452:0:b0:651:69d7:3d6a with SMTP id e18-20020a0cb452000000b0065169d73d6amr16259891qvf.15.1694029405688; Wed, 06 Sep 2023 12:43:25 -0700 (PDT) Received: from [192.168.1.88] (192-0-143-139.cpe.teksavvy.com. [192.0.143.139]) by smtp.gmail.com with ESMTPSA id j9-20020a0ce009000000b0064aa51f9978sm5662918qvk.115.2023.09.06.12.43.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Sep 2023 12:43:25 -0700 (PDT) Message-ID: Date: Wed, 6 Sep 2023 15:43:23 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 01/13] [APX EGPR] middle-end: Add insn argument to base_reg_class To: Hongyu Wang , Uros Bizjak Cc: Hongyu Wang , jakub@redhat.com, gcc-patches@gcc.gnu.org, hongtao.liu@intel.com, hubicka@ucw.cz References: <20230831082024.314097-1-hongyu.wang@intel.com> <20230831082024.314097-2-hongyu.wang@intel.com> From: Vladimir Makarov In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: On 9/1/23 05:07, Hongyu Wang wrote: > Uros Bizjak via Gcc-patches 于2023年8月31日周四 18:16写道： >> On Thu, Aug 31, 2023 at 10:20 AM Hongyu Wang wrote: >>> From: Kong Lingling >>> >>> Current reload infrastructure does not support selective base_reg_class >>> for backend insn. Add insn argument to base_reg_class for >>> lra/reload usage. >> I don't think this is the correct approach. Ideally, a memory >> constraint should somehow encode its BASE/INDEX register class. >> Instead of passing "insn", simply a different constraint could be used >> in the constraint string of the relevant insn. > We tried constraint only at the beginning, but then we found the > reload infrastructure > does not work like that. > > The BASE/INDEX reg classes are determined before choosing alternatives, in > process_address under curr_insn_transform. Process_address creates the mem > operand according to the BASE/INDEX reg class. Then, the memory operand > constraint check will evaluate the mem op with targetm.legitimate_address_p. > > If we want to make use of EGPR in base/index we need to either extend BASE/INDEX > reg class in the backend, or, for specific insns, add a target hook to > tell reload > that the extended reg class with EGPR can be used to construct memory operand. > > CC'd Vladimir as git send-mail failed to add recipient. > > I think the approach proposed by Intel developers is better.  In some way we already use such approach when we pass memory mode to get the base reg class.  Although we could use different memory constraints for different modes when the possible base reg differs for some memory modes. Using special memory constraints probably can be implemented too (I understand attractiveness of such approach for readability of the machine description).  But in my opinion it will require much bigger work in IRA/LRA/reload.  It also significantly slow down RA as we need to process insn constraints for processing each memory in many places (e.g. for calculation of reg classes and costs in IRA).  Still I think there will be a few cases for this approach resulting in a bigger probability of assigning hard reg out of specific base reg class and this will result in additional reloads. So the approach proposed by Intel is ok for me.  Although if x86 maintainers are strongly against this approach and the changes in x86 machine dependent code and Intel developers implement Uros approach, I am ready to review this.  But still I prefer the current Intel developers approach for reasons I mentioned above.