diff mbox

[AVX512,81.1/n] Extend `function_code' field in `tree_var_decl' structure.

Message ID 20141022075113.GA11644@msticlxl57.ims.intel.com
State New
Headers show

Commit Message

Kirill Yukhin Oct. 22, 2014, 7:51 a.m. UTC 
Hello,
Patch was separated into two parts: tree-core.h changes and target
changes.
On 21 Oct 16:20, Jakub Jelinek wrote:
> On Tue, Oct 21, 2014 at 06:08:15PM +0400, Kirill Yukhin wrote:
> > --- a/gcc/tree.h
> > +++ b/gcc/tree.h
> > @@ -2334,6 +2334,10 @@ extern void decl_value_expr_insert (tree, tree);
> >  #define DECL_COMDAT(NODE) \
> >    (DECL_WITH_VIS_CHECK (NODE)->decl_with_vis.comdat_flag)
> >  
> > + /* In a FUNCTION_DECL indicates that a static chain is needed.  */
> > +#define DECL_STATIC_CHAIN(NODE) \
> > +  (DECL_WITH_VIS_CHECK (NODE)->decl_with_vis.regdecl_flag)
> > +
> 
> I would say that you should still keep it together with the FUNCTION_DECL
> macros and use FUNCTION_DECL_CHECK there, to make it clear we don't want
> the macro to be used on VAR_DECLs etc.
> So just s/function_decl/decl_with_vis/ in the definition IMHO.
Thanks, updated.
Also taken into account Richard's input about logical groping of the fields.

> Also, with so many added builtins, how does it affect
> int i;
> compilation time at -O0?  If it is significant, maybe it is highest time to
> make the md builtin decl building more lazy.
As mentioned in previous mail, change is less than 1%.
But I will put the task of making built-ins lazy into the queue (probably after
AVX-512 and offload are finished).

gcc/
	* tree-core.h (tree_var_decl): Extend `function_code' field
	by one bit, move `regdecl_flag' field to ...
	(tree_decl_with_vis): Here.
	* tree.h (DECL_STATIC_CHAIN): Update struct name.
	

Bootstrapped.

Is it ok for trunk?
> 
> 	Jakub

Comments

Jakub Jelinek Oct. 23, 2014, 10:58 a.m. UTC | #1 
On Wed, Oct 22, 2014 at 11:51:32AM +0400, Kirill Yukhin wrote:
> gcc/
> 	* tree-core.h (tree_var_decl): Extend `function_code' field
> 	by one bit, move `regdecl_flag' field to ...
> 	(tree_decl_with_vis): Here.
> 	* tree.h (DECL_STATIC_CHAIN): Update struct name.
> 	
> 
> Bootstrapped.
> 
> Is it ok for trunk?

Ok for trunk for now, I hope we can reduce the number of builtins in the future
though.  Even the current 1470 i?86 builtins is too big IMHO, and if you add
hundreds further builtins...

	Jakub
diff mbox

Patch

diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index b69312b..30db893 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1498,7 +1498,9 @@  struct GTY(()) tree_decl_with_vis {
  unsigned cxx_destructor : 1;
  /* Belong to FUNCTION_DECL exclusively.  */
  unsigned final : 1;
- /* 15 unused bits. */
+ /* Belong to FUNCTION_DECL exclusively.  */
+ unsigned regdecl_flag : 1;
+ /* 14 unused bits. */
 };
 
 struct GTY(()) tree_var_decl {
@@ -1539,20 +1541,19 @@  struct GTY(()) tree_function_decl {
      DECL_FUNCTION_CODE.  Otherwise unused.
      ???  The bitfield needs to be able to hold all target function
 	  codes as well.  */
-  ENUM_BITFIELD(built_in_function) function_code : 11;
+  ENUM_BITFIELD(built_in_function) function_code : 12;
   ENUM_BITFIELD(built_in_class) built_in_class : 2;
 
   unsigned static_ctor_flag : 1;
   unsigned static_dtor_flag : 1;
-  unsigned uninlinable : 1;
 
+  unsigned uninlinable : 1;
   unsigned possibly_inlined : 1;
   unsigned novops_flag : 1;
   unsigned returns_twice_flag : 1;
   unsigned malloc_flag : 1;
   unsigned operator_new_flag : 1;
   unsigned declared_inline_flag : 1;
-  unsigned regdecl_flag : 1;
   unsigned no_inline_warning_flag : 1;
 
   unsigned no_instrument_function_entry_exit : 1;
diff --git a/gcc/tree.h b/gcc/tree.h
index 45f127f..2a085c9 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -2553,7 +2553,7 @@  extern void decl_fini_priority_insert (tree, priority_type);
 
 /* In a FUNCTION_DECL indicates that a static chain is needed.  */
 #define DECL_STATIC_CHAIN(NODE) \
-  (FUNCTION_DECL_CHECK (NODE)->function_decl.regdecl_flag)
+  (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.regdecl_flag)
 
 /* Nonzero for a decl that cgraph has decided should be inlined into
    at least one call site.  It is not meaningful to look at this