Patchwork RFC: Using DECL_NO_LIMIT_STACK as a backend specific flag

login
register
mail settings
Submitter Nick Clifton
Date Oct. 3, 2012, 1:31 p.m.
Message ID <871uhfsmw2.fsf@redhat.com>
Download mbox | patch
Permalink /patch/188771/
State New
Headers show

Comments

Nick Clifton - Oct. 3, 2012, 1:31 p.m.
Hi Guys,

  Is there a target specific way to add a flag bit to a function decl ?

  For the RX port I want to be able to mark a function decl for which I
  have issued a warning message.  Unfortunately I could find no easy way
  to do this other than stealing one of the generic bits (no_limit_stack
  in this case).  Is there a proper way to do this ?

  I have attached my current implementation to demonstrate the problem.

Cheers
  Nick
Ian Taylor - Oct. 3, 2012, 2:02 p.m.
On Wed, Oct 3, 2012 at 6:31 AM, Nick Clifton <nickc@redhat.com> wrote:
>
>   Is there a target specific way to add a flag bit to a function decl ?
>
>   For the RX port I want to be able to mark a function decl for which I
>   have issued a warning message.  Unfortunately I could find no easy way
>   to do this other than stealing one of the generic bits (no_limit_stack
>   in this case).  Is there a proper way to do this ?

Can't you just keep a list of the decls for which you have issued the
warning?  How many decls do you expect to be on that list?

Ian
Nick Clifton - Oct. 3, 2012, 3:20 p.m.
Hi Ian,

> Can't you just keep a list of the decls for which you have issued the
> warning?

Yes - that would work too.  In fact I agree that this would be cleaner 
solution in my particular case.  I'll create a new patch...


> How many decls do you expect to be on that list?

Not very many.  Maybe two or three at most.

But I am interested to know if there is a way for targets to add their 
own information to function decls (and decls in general).  If not for 
this particular case, then for problems to come in the future.

Cheers
   Nick
Richard Guenther - Oct. 4, 2012, 7:57 a.m.
On Wed, Oct 3, 2012 at 5:20 PM, nick clifton <nickc@redhat.com> wrote:
> Hi Ian,
>
>
>> Can't you just keep a list of the decls for which you have issued the
>> warning?
>
>
> Yes - that would work too.  In fact I agree that this would be cleaner
> solution in my particular case.  I'll create a new patch...
>
>
>
>> How many decls do you expect to be on that list?
>
>
> Not very many.  Maybe two or three at most.
>
> But I am interested to know if there is a way for targets to add their own
> information to function decls (and decls in general).  If not for this
> particular case, then for problems to come in the future.

To the decl not.  But I suppose you are only looking at defined functions,
so it should suffice to amend struct function.  It's reasonable to allow
the target to associate extra info with struct function and we already
have a way to do that via the init_machine_status target hook.

Richard.

> Cheers
>   Nick
>
>

Patch

Index: gcc/config/rx/rx.c
===================================================================
--- gcc/config/rx/rx.c	(revision 192034)
+++ gcc/config/rx/rx.c	(working copy)
@@ -1288,6 +1288,24 @@ 
       target_reinit ();
     }
 
+  if (current_is_fast_interrupt && rx_warn_multiple_fast_interrupts)
+    {
+      static tree prev_fast_interrupt = NULL_TREE;
+
+      if (prev_fast_interrupt == NULL_TREE)
+	prev_fast_interrupt = fndecl;
+      else if (prev_fast_interrupt != fndecl
+	       && ! DECL_NO_LIMIT_STACK (fndecl))
+	{
+	  warning (0, "multiple fast interrupt routines seen: %qE and %qE",
+		   fndecl, prev_fast_interrupt);
+	  /* FIXME: We use the no_limit_stack bit in the tree_function_decl
+	     structure to mark functions for which we have issued this warning.
+	     There probably ought to be another way to do this.  */
+	  DECL_NO_LIMIT_STACK (fndecl) = 1;
+	}
+    }
+
   rx_previous_fndecl = fndecl;
 }
 
Index: gcc/config/rx/rx.opt
===================================================================
--- gcc/config/rx/rx.opt	(revision 192034)
+++ gcc/config/rx/rx.opt	(working copy)
@@ -118,3 +118,9 @@ 
 mpid
 Target Mask(PID)
 Enables Position-Independent-Data (PID) mode.
+
+;---------------------------------------------------
+
+mwarn-multiple-fast-interrupts
+Target Report Var(rx_warn_multiple_fast_interrupts) Init(1) Warning
+Warn when multiple, different, fast interrupt handlers are in the compilation unit.
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi	(revision 192034)
+++ gcc/doc/invoke.texi	(working copy)
@@ -859,6 +859,7 @@ 
 -mmax-constant-size=@gol
 -mint-register=@gol
 -mpid@gol
+-mno-warn-multiple-fast-interrupts@gol
 -msave-acc-in-interrupts}
 
 @emph{S/390 and zSeries Options}
@@ -17875,6 +17876,15 @@ 
 By default this feature is not enabled.  The default can be restored
 via the @option{-mno-pid} command-line option.
 
+@item -mno-warn-multiple-fast-interrupts
+@itemx -mwarn-multiple-fast-interrupts
+@opindex mno-warn-multiple-fast-interrupts
+@opindex mwarn-multiple-fast-interrupts
+Prevents GCC from issuing a warning message if it finds more than one
+fast interrupt handler when it is compiling a file.  The default is to
+issue a warning for each extra fast interrupt handler found, as the RX
+only supports one such interrupt.
+
 @end table
 
 @emph{Note:} The generic GCC command-line option @option{-ffixed-@var{reg}}