public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Edwin Lu <ewlu@rivosinc.com>
To: Robin Dapp <rdapp.gcc@gmail.com>, gcc-patches@gcc.gnu.org
Cc: gnu-toolchain@rivosinc.com
Subject: Re: [COMMITTED V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation
Date: Wed, 31 Jan 2024 17:42:41 -0800	[thread overview]
Message-ID: <825e841c-b715-44cd-8cdd-b722865b4f7f@rivosinc.com> (raw)
In-Reply-To: <30de6dd9-7d97-43b6-9874-c197f5c31659@gmail.com>

On 1/25/2024 9:06 AM, Robin Dapp wrote:
>>     /* If we ever encounter an insn without an insn reservation, trip
>>        an assert so we can find and fix this problem.  */
>> -#if 0
>> +  if (! insn_has_dfa_reservation_p (insn)) {
>> +    print_rtl(stderr, insn);
>> +    fprintf(stderr, "%d", get_attr_type (insn));
>> +  }
>>     gcc_assert (insn_has_dfa_reservation_p (insn));
>> -#endif
>>   
>>     return more - 1;
>>   }
> 
> I was thinking about make the gcc_assert a gcc_checking_assert so,
> in case we accidentally forget something at any point, it would
> only gracefully degrade in a release build.  As we already have
> a hard assert for the type the patch (and not many test with
> enable checking anyway) this is OK IMHO.
> 
> I suppose you tested with all available -mtune options?
> 
> Regards
>   Robin
> 
> 

Committed without the debugging stuff!

Edwin

WARNING: multiple messages have this Message-ID
From: Edwin Lu <ewlu@rivosinc.com>
To: gcc-patches@gcc.gnu.org
Cc: gnu-toolchain@rivosinc.com
Subject: Re: [COMMITTED V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation
Date: Wed, 31 Jan 2024 17:42:41 -0800	[thread overview]
Message-ID: <825e841c-b715-44cd-8cdd-b722865b4f7f@rivosinc.com> (raw)
Message-ID: <20240201014241.1b8rAOE_cXijSiFhODHQK3UhBMdrVq2sSwqtMAqbjI4@z> (raw)
In-Reply-To: <30de6dd9-7d97-43b6-9874-c197f5c31659@gmail.com>

On 1/25/2024 9:06 AM, Robin Dapp wrote:
>>     /* If we ever encounter an insn without an insn reservation, trip
>>        an assert so we can find and fix this problem.  */
>> -#if 0
>> +  if (! insn_has_dfa_reservation_p (insn)) {
>> +    print_rtl(stderr, insn);
>> +    fprintf(stderr, "%d", get_attr_type (insn));
>> +  }
>>     gcc_assert (insn_has_dfa_reservation_p (insn));
>> -#endif
>>   
>>     return more - 1;
>>   }
> 
> I was thinking about make the gcc_assert a gcc_checking_assert so,
> in case we accidentally forget something at any point, it would
> only gracefully degrade in a release build.  As we already have
> a hard assert for the type the patch (and not many test with
> enable checking anyway) this is OK IMHO.
> 
> I suppose you tested with all available -mtune options?
> 
> Regards
>   Robin
> 
> 

Committed without the debugging stuff!

Edwin


  parent reply	other threads:[~2024-02-01  1:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12 18:08 [PATCH V3 0/4] RISC-V: Associate typed insns to dfa reservation Edwin Lu
2024-01-12 18:08 ` [PATCH V3 1/4] RISC-V: Add non-vector types to dfa pipelines Edwin Lu
2024-01-25 17:06   ` Robin Dapp
2024-02-01  1:41     ` [COMMITTED " Edwin Lu
2024-02-01  1:41       ` Edwin Lu
2024-01-12 18:08 ` [PATCH V3 2/4] RISC-V: Add vector related pipelines Edwin Lu
2024-01-25 17:06   ` Robin Dapp
2024-01-26 18:25     ` Edwin Lu
2024-01-30 19:39       ` Robin Dapp
2024-01-12 18:08 ` [PATCH V3 3/4] RISC-V: Use default cost model for insn scheduling Edwin Lu
2024-01-25 17:06   ` Robin Dapp
2024-01-26 18:31     ` Edwin Lu
2024-01-26 18:31       ` Edwin Lu
2024-02-01  1:41     ` [COMMITTED " Edwin Lu
2024-02-01  1:41       ` Edwin Lu
2024-01-12 18:08 ` [PATCH V3 4/4] RISC-V: Enable assert for insn_has_dfa_reservation Edwin Lu
2024-01-25 17:06   ` Robin Dapp
2024-01-26 18:37     ` Edwin Lu
2024-01-26 18:37       ` Edwin Lu
2024-02-01  1:42     ` Edwin Lu [this message]
2024-02-01  1:42       ` [COMMITTED " Edwin Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=825e841c-b715-44cd-8cdd-b722865b4f7f@rivosinc.com \
    --to=ewlu@rivosinc.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gnu-toolchain@rivosinc.com \
    --cc=rdapp.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).