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.129.124]) by sourceware.org (Postfix) with ESMTPS id BA5F73858D20 for ; Fri, 11 Aug 2023 16:02:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BA5F73858D20 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=1691769745; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oh3Pe2dSfJXqsmCNlBGcXWM0LntAzSaV9ehOMz+Bg4s=; b=EXbEfgl+mQZmOp96Bg9IYFcDZempw2aer78NmrgmqNORzpvDxwsxvRZzSWYyJamXDF7fuj 1omXMrJJEtlZKRKjvGzsg/hf6A7WcRYSHA6Q0btWe86PPtqUiu6Warf+y+L1K+aKOZtksq b5PX4MsvptlgZQL+Qov1ktkamgqE4ok= Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-693-ZLpK5x0fMGSEDxl2ByQlXQ-1; Fri, 11 Aug 2023 12:02:17 -0400 X-MC-Unique: ZLpK5x0fMGSEDxl2ByQlXQ-1 Received: by mail-oi1-f198.google.com with SMTP id 5614622812f47-3a751d44acdso2511893b6e.1 for ; Fri, 11 Aug 2023 09:02:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691769735; x=1692374535; h=content-transfer-encoding:in-reply-to:from:references: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=oh3Pe2dSfJXqsmCNlBGcXWM0LntAzSaV9ehOMz+Bg4s=; b=XYLyc3HLdwj9/sABYz+sm9VgNaBVFfBSwgXiQuSvxVK0gjeIlGmKY5LEs2A/nfoDeY t5mnh4eYSOgjLQ1wBZMAtSwf+fu5/4yqy6d5QuAh4DQF+bhKqCowdDEqaelNl+5Yo3so qM/VCoeRvOuxE7kB9j6UlHJOyydvaTZXwLGDEIwjtRHDCu/+pMaKQ/d4pXBIhdBv9JWq kaXk1tGOYyvxSUvx8y51PSnMHU5Vbu1qfr+imcD3omqbFXGJ3HQPlWD1naEoluUZQ1FZ J1tlQbTEn/Ev55cOBI9Ox+V5mPZQTVhc8xyCFhE0RNf7qne1AbrnKZYTNB5Kee80lS1v rs/g== X-Gm-Message-State: AOJu0YzLpxoPmCsCNNb2uverKBnhEPQpT1RBK1py/4N7YKJkk/jFZnjt 8dT0d/FxXijJfmHxxL3YBmt73X+IyhmOGe+P/oSIUSP6CIfng9Whett+iV/dqzo4hv8PD/OeogC aUG/WlWLD+WbBAw0= X-Received: by 2002:aca:3482:0:b0:3a7:72e2:2782 with SMTP id b124-20020aca3482000000b003a772e22782mr2200137oia.50.1691769735429; Fri, 11 Aug 2023 09:02:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFoGgUTdurHZM9VaRceJCCgzohS+P4ppgcvz88UpVJRPT4t1jia9z7XiItQ3IC1Zv9zztwJYg== X-Received: by 2002:aca:3482:0:b0:3a7:72e2:2782 with SMTP id b124-20020aca3482000000b003a772e22782mr2200108oia.50.1691769734958; Fri, 11 Aug 2023 09:02:14 -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 b10-20020a0ccd0a000000b0063d14bfa5absm1311344qvm.36.2023.08.11.09.02.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Aug 2023 09:02:14 -0700 (PDT) Message-ID: Date: Fri, 11 Aug 2023 12:02:13 -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: LRA for avr: help with FP and elimination To: SenthilKumar.Selvaraj@microchip.com, gcc@gcc.gnu.org References: <997f2d86-9c4d-7875-5f88-b1b4ff89b560@redhat.com> <008a3f24e43c76b2de9ebe11b5fe46d4683cb598.camel@microchip.com> <7f76eec7-f31e-8bd1-79a2-477784aefaf6@redhat.com> <76415e07634c703dc588169550c3fb8c0549cfa8.camel@microchip.com> From: Vladimir Makarov In-Reply-To: <76415e07634c703dc588169550c3fb8c0549cfa8.camel@microchip.com> 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=-6.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,WEIRD_PORT 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 8/10/23 07:33, SenthilKumar.Selvaraj@microchip.com wrote: > > Hi Vlad, > > I can confirm your commit (https://gcc.gnu.org/git?p=gcc.git;a=commit;h=2971ff7b1d564ac04b537d907c70e6093af70832) > fixes the above problem, thank you. However, I see execution failures if a > pseudo assigned to FP has to be spilled because of stack slot creation. > > To reproduce, build the compiler just like above, and then do > > $ avr-gcc -mmcu=avr51 /gcc/testsuite/gcc.c-torture/execute/20050224-1.c -O2 -S -fdump-rtl-all > > The execution failure occurs at this point > > movw r24,r2 > sbiw r24,36 > brne .L8 > > r2 is never set anywhere at all in the assembly. > > The relevant insns (in the IRA dump) are > > (insn 3 15 4 3 (set (reg/v:HI 51 [ j ]) > (const_int 0 [0])) "gcc/gcc/testsuite/gcc.c-torture/execute/20050224-1.c":19:21 101 {*movhi_split} > (expr_list:REG_EQUAL (const_int 0 [0]) > (nil))) > ... > (insn 28 27 67 8 (parallel [ > (set (reg/v:HI 51 [ j ]) > (plus:HI (reg/v:HI 51 [ j ]) > (const_int 1 [0x1]))) > (clobber (scratch:QI)) > ]) "/home/i41766/code/personal/gcc/gcc/testsuite/gcc.c-torture/execute/20050224-1.c":28:8 175 {addhi3_clobber} > (nil)) > ... > (jump_insn 44 43 45 13 (parallel [ > (set (pc) > (if_then_else (ne (reg/v:HI 51 [ j ]) > (const_int 36 [0x24])) > (label_ref:HI 103) > (pc))) > (clobber (scratch:QI)) > ]) "/home/i41766/code/personal/gcc/gcc/testsuite/gcc.c-torture/execute/20050224-1.c":11:16 discrim 1 713 {cbranchhi4_insn} > (expr_list:REG_DEAD (reg/v:HI 51 [ j ]) > (int_list:REG_BR_PROB 7 (nil))) > -> 103) > > LRA deletes insns 3 and 28, and uses r2 in the jump_insn. > > In the reload dump, for pseudo r51, I'm seeing this > subreg regs: > Frame pointer can not be eliminated anymore > Spilling non-eliminable hard regs: 28 29 > Spilling r51(28) > Slot 0 regnos (width = 0): 46 > Slot 1 regnos (width = 0): 45 > > lra_update_fp2sp_elimination calls spill_pseudos with > HARD_FRAME_POINTER_REGNUM, and that sets reg_renumber[51] to -1. > > Later down the line, process_bb_lives is called with dead_insn_p=true from > lra_create_lives_ranges_1 on the relevant BB (#8), and df_get_live_out > on that BB does not contain 51 (even though previous calls to the same BB did). > > Breakpoint 8, process_bb_lives (bb=0x7fffea570240, curr_point=@0x7fffffffd838: 25, dead_insn_p=true) at gcc/gcc/lra-lives.cc:664 > 664 function_abi last_call_abi = default_function_abi; > (gdb) n > 666 reg_live_out = df_get_live_out (bb); > (gdb) > 667 sparseset_clear (pseudos_live); > (gdb) p debug_bitmap(reg_live_out) > > first = 0x321c128 current = 0x321c128 indx = 0 > 0x321c128 next = (nil) prev = (nil) indx = 0 > bits = { 28 32 34 43 44 47 48 49 50 } > > process_bb_lives then considers the insn setting 51 (and > the reload insns LRA created) as dead, and removes them. > > BB 8 > Insn 67: point = 31, n_alt = -1 > Insn 114: point = 31, n_alt = 3 > Deleting dead insn 114 > deleting insn with uid = 114. > Insn 28: point = 31, n_alt = 1 > Deleting dead insn 28 > deleting insn with uid = 28. > Insn 113: point = 31, n_alt = 2 > Deleting dead insn 113 > > Same for insn 3 as well > > BB 3 > Insn 92: point = 40, n_alt = -1 > Insn 5: point = 40, n_alt = 1 > Insn 4: point = 41, n_alt = 3 > Insn 3: point = 42, n_alt = 3 > Deleting dead insn 3 > deleting insn with uid = 3. > > Yet when it prints "Global pseudo live data has been updated" after > all this, r51 is live again :( > > BB 8: > livein: 8: > > 43 44 47 48 49 50 51 > liveout: 8: > > 28 32 34 43 44 47 48 49 50 51 > > Eventually, it assigns 2 to r51, resulting in just the compare and > branch instruction remaining in the assembly. > > Is this an LRA bug or is the target doing something wrong? > I've reproduced this.  Probably it is a bug with live info update when fp->sp elimination became invalid. I'll start to work on this problem on the next week and hope to have a fix soon after that.