public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Sebastian Huber <sebastian.huber@embedded-brains.de>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: devel@rtems.org, gcc-patches@gcc.gnu.org
Subject: Re: [gcc] RTEMS: Tune multilib selection
Date: Fri, 24 Feb 2023 07:23:13 +0100	[thread overview]
Message-ID: <ae49fe2b-4c9f-3567-545c-402d016a6c13@embedded-brains.de> (raw)
In-Reply-To: <mhng-fb5b6088-09b2-41c8-a6c9-fd8b89fc8907@palmer-ri-x1c9a>

On 23.02.23 19:38, Palmer Dabbelt wrote:
> On Thu, 23 Feb 2023 03:48:26 PST (-0800), 
> sebastian.huber@embedded-brains.de wrote:
>> gcc/ChangeLog:
>>
>>     * config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs.
>>     Add non-compact 32-bit multilibs.
>> ---
>>  gcc/config/riscv/t-rtems | 17 +++++++++--------
>>  1 file changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/gcc/config/riscv/t-rtems b/gcc/config/riscv/t-rtems
>> index 41f5927fc87..19b12030895 100644
>> --- a/gcc/config/riscv/t-rtems
>> +++ b/gcc/config/riscv/t-rtems
>> @@ -1,8 +1,8 @@
>>  MULTILIB_OPTIONS    =
>>  MULTILIB_DIRNAMES    =
>>
>> -MULTILIB_OPTIONS    += 
>> march=rv32i/march=rv32im/march=rv32imafd/march=rv32iac/march=rv32imac/march=rv32imafc/march=rv64imafd/march=rv64imac/march=rv64imafdc
>> -MULTILIB_DIRNAMES    += rv32i       rv32im       rv32imafd 
>> rv32iac       rv32imac       rv32imafc       rv64imafd rv64imac       
>> rv64imafdc
>> +MULTILIB_OPTIONS    += 
>> march=rv32i/march=rv32iac/march=rv32im/march=rv32ima/march=rv32imac/march=rv32imaf/march=rv32imafc/march=rv32imafd/march=rv32imafdc/march=rv64ima/march=rv64imac/march=rv64imafd/march=rv64imafdc
>> +MULTILIB_DIRNAMES    += rv32i       rv32iac       rv32im 
>> rv32ima       rv32imac       rv32imaf       rv32imafc rv32imafd       
>> rv32imafdc       rv64ima       rv64imac rv64imafd       rv64imafdc
>>
>>  MULTILIB_OPTIONS    += 
>> mabi=ilp32/mabi=ilp32f/mabi=ilp32d/mabi=lp64/mabi=lp64d
>>  MULTILIB_DIRNAMES    += ilp32      ilp32f      ilp32d      lp64      
>> lp64d
>> @@ -12,14 +12,15 @@ MULTILIB_DIRNAMES    += medany
>>
>>  MULTILIB_REQUIRED    =
>>  MULTILIB_REQUIRED    += march=rv32i/mabi=ilp32
>> -MULTILIB_REQUIRED    += march=rv32im/mabi=ilp32
>> -MULTILIB_REQUIRED    += march=rv32imafd/mabi=ilp32d
>>  MULTILIB_REQUIRED    += march=rv32iac/mabi=ilp32
>> +MULTILIB_REQUIRED    += march=rv32im/mabi=ilp32
>> +MULTILIB_REQUIRED    += march=rv32ima/mabi=ilp32
>>  MULTILIB_REQUIRED    += march=rv32imac/mabi=ilp32
>> +MULTILIB_REQUIRED    += march=rv32imaf/mabi=ilp32f
>>  MULTILIB_REQUIRED    += march=rv32imafc/mabi=ilp32f
>> -MULTILIB_REQUIRED    += march=rv64imafd/mabi=lp64d
>> -MULTILIB_REQUIRED    += march=rv64imafd/mabi=lp64d/mcmodel=medany
>> -MULTILIB_REQUIRED    += march=rv64imac/mabi=lp64
>> +MULTILIB_REQUIRED    += march=rv32imafd/mabi=ilp32d
>> +MULTILIB_REQUIRED    += march=rv32imafdc/mabi=ilp32d
>> +MULTILIB_REQUIRED    += march=rv64ima/mabi=lp64/mcmodel=medany
>>  MULTILIB_REQUIRED    += march=rv64imac/mabi=lp64/mcmodel=medany
>> -MULTILIB_REQUIRED    += march=rv64imafdc/mabi=lp64d
>> +MULTILIB_REQUIRED    += march=rv64imafd/mabi=lp64d/mcmodel=medany
>>  MULTILIB_REQUIRED    += march=rv64imafdc/mabi=lp64d/mcmodel=medany
> 
> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
> 
> IMO it's fine to remove multilibs from the default set.  It could be 
> seen as breaking users, but IIRC last time we talked about something 
> like this it was OK as otherwise we're going to end up with a huge set 
> of multilibs for defunct ISAs.  This one is also extra safe, since 
> moving to medany shouldn't break any users (aside from maybe a slight 
> performance issue).

Thanks for the review. Which performance issue may show up here?
> 
> Are you aiming for GCC-13 with this?  I wouldn't be opposed to that: 
> there's some risk of breaking users this late in the process, but my 
> guess is that most of them aren't looking until release anyway.  Still 
> better to hold off, but if there's something in RTEMS land that benefits 
> from this being early then I think it's fine.

RTEMS has its own release cycle, so I would back port this change to all 
GCC branches which may be used with RTEMS 6 and this is GCC 10 or later.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

      reply	other threads:[~2023-02-24  6:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23 11:48 Sebastian Huber
2023-02-23 18:38 ` Palmer Dabbelt
2023-02-24  6:23   ` Sebastian Huber [this message]

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=ae49fe2b-4c9f-3567-545c-402d016a6c13@embedded-brains.de \
    --to=sebastian.huber@embedded-brains.de \
    --cc=devel@rtems.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=palmer@dabbelt.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).