public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Advice on how to disable floating point instructions
@ 2023-11-04 16:40 Enrico
  2023-11-04 18:08 ` Andrew Pinski
  0 siblings, 1 reply; 3+ messages in thread
From: Enrico @ 2023-11-04 16:40 UTC (permalink / raw)
  To: gcc

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

Hello,


for a custom architecture I am working on, I would like to entirely disable
the usage of hardware floating point instructions in favor of library
methods on demand.

I need advice on what is the best strategy to do this. My idea is to:

- create  a new flag (let's say -m[no-]float-insn or something like that

- use the value of the flag in the condition of every define_insn in the
machine description to inhibit their usage if the flag is active


My questions:

- Is this a good strategy? Or would you suggest a better solution?

- If I switch all floating point instructions off, will GCC automatically
use their software counterpart, from the builtins or libraries, by finding
them via their instruction patterns?

- I noticed that some opcodes of our architecture can be found in the
assembler, but they are not available in the GCC backend. How can I inhibit
the usage of those instructions? Shall I explicitly add to the machine
description and then disable them with their condition?


Thank you for your suggestions.

I am new in this (difficult) business and I am trying to learn.


Kind regards

Enrico Bragante

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Advice on how to disable floating point instructions
  2023-11-04 16:40 Advice on how to disable floating point instructions Enrico
@ 2023-11-04 18:08 ` Andrew Pinski
  2023-11-05  7:44   ` Enrico
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Pinski @ 2023-11-04 18:08 UTC (permalink / raw)
  To: Enrico; +Cc: gcc

On Sat, Nov 4, 2023 at 9:41 AM Enrico via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hello,
>
>
> for a custom architecture I am working on, I would like to entirely disable
> the usage of hardware floating point instructions in favor of library
> methods on demand.
>
> I need advice on what is the best strategy to do this. My idea is to:
>
> - create  a new flag (let's say -m[no-]float-insn or something like that

A few backends use -msoft-float to handle that. (mips and rs6000 for examples).
And yes GCC outputs library calls for floating point in those cases.

Thanks,
Andrew

>
> - use the value of the flag in the condition of every define_insn in the
> machine description to inhibit their usage if the flag is active
>
>
> My questions:
>
> - Is this a good strategy? Or would you suggest a better solution?
>
> - If I switch all floating point instructions off, will GCC automatically
> use their software counterpart, from the builtins or libraries, by finding
> them via their instruction patterns?
>
> - I noticed that some opcodes of our architecture can be found in the
> assembler, but they are not available in the GCC backend. How can I inhibit
> the usage of those instructions? Shall I explicitly add to the machine
> description and then disable them with their condition?
>
>
> Thank you for your suggestions.
>
> I am new in this (difficult) business and I am trying to learn.
>
>
> Kind regards
>
> Enrico Bragante

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Advice on how to disable floating point instructions
  2023-11-04 18:08 ` Andrew Pinski
@ 2023-11-05  7:44   ` Enrico
  0 siblings, 0 replies; 3+ messages in thread
From: Enrico @ 2023-11-05  7:44 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: gcc

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

Thank you Andrew for the hint.

I noticed that the option Mask() is used a lot with the flag msoft-float.
The documentation states that Mask sets a flag in the target_flags
variable.
What is the advantage of setting a flag in target_flags, compared to using
Var() on a custom variable?

Thank you
Best regards
Enrico

Il sab 4 nov 2023, 19:08 Andrew Pinski <pinskia@gmail.com> ha scritto:

> On Sat, Nov 4, 2023 at 9:41 AM Enrico via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > Hello,
> >
> >
> > for a custom architecture I am working on, I would like to entirely
> disable
> > the usage of hardware floating point instructions in favor of library
> > methods on demand.
> >
> > I need advice on what is the best strategy to do this. My idea is to:
> >
> > - create  a new flag (let's say -m[no-]float-insn or something like that
>
> A few backends use -msoft-float to handle that. (mips and rs6000 for
> examples).
> And yes GCC outputs library calls for floating point in those cases.
>
> Thanks,
> Andrew
>
> >
> > - use the value of the flag in the condition of every define_insn in the
> > machine description to inhibit their usage if the flag is active
> >
> >
> > My questions:
> >
> > - Is this a good strategy? Or would you suggest a better solution?
> >
> > - If I switch all floating point instructions off, will GCC automatically
> > use their software counterpart, from the builtins or libraries, by
> finding
> > them via their instruction patterns?
> >
> > - I noticed that some opcodes of our architecture can be found in the
> > assembler, but they are not available in the GCC backend. How can I
> inhibit
> > the usage of those instructions? Shall I explicitly add to the machine
> > description and then disable them with their condition?
> >
> >
> > Thank you for your suggestions.
> >
> > I am new in this (difficult) business and I am trying to learn.
> >
> >
> > Kind regards
> >
> > Enrico Bragante
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-11-05  7:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-04 16:40 Advice on how to disable floating point instructions Enrico
2023-11-04 18:08 ` Andrew Pinski
2023-11-05  7:44   ` Enrico

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).