diff mbox

Kill TYPE_METHODS rtl 3/9

Message ID c654a003-472f-4243-ea46-f2bbc6d96927@acm.org
State New
Headers show

Commit Message

Nathan Sidwell July 14, 2017, 4:54 p.m. UTC
This was the most surprising check of TYPE_METHODS.  When not optimizing we use 
the non-nullness of TYPE_METHODS to figure out if we want to place a non BLKmode 
structure into a register.  On the grounds that one can't call a member function 
with a register-located object.

That seems overly enthusiastic -- if we're not optimizing, who cares?

(When we zap TYHPE_METHODS we currently set it to error_mark_node, if it was 
non-null, so that this above check will work).

I'd appreciate comment.

nathan

Comments

Jeff Law July 15, 2017, 4:43 a.m. UTC | #1
On 07/14/2017 10:54 AM, Nathan Sidwell wrote:
> This was the most surprising check of TYPE_METHODS.  When not optimizing
> we use the non-nullness of TYPE_METHODS to figure out if we want to
> place a non BLKmode structure into a register.  On the grounds that one
> can't call a member function with a register-located object.
> 
> That seems overly enthusiastic -- if we're not optimizing, who cares?
> 
> (When we zap TYHPE_METHODS we currently set it to error_mark_node, if it
> was non-null, so that this above check will work).
> 
> I'd appreciate comment.
Definitely a surprise.  I was hatching an idea this might be related to
the old stupid.c allocator, but it turns out this code is much newer
than that.

If I'm reading BZ39485 correctly, the issue is that when not optimizing,
we were shoving the value into a register rather than dumping it into
memory.

As a result gdb was unable to do an inferior call to its the object's
methods.

Egad.

jeff
Nathan Sidwell July 15, 2017, 12:20 p.m. UTC | #2
On 07/15/2017 12:43 AM, Jeff Law wrote:
> On 07/14/2017 10:54 AM, Nathan Sidwell wrote:
>> This was the most surprising check of TYPE_METHODS.  When not optimizing
>> we use the non-nullness of TYPE_METHODS to figure out if we want to
>> place a non BLKmode structure into a register.  On the grounds that one
>> can't call a member function with a register-located object.
>>
>> That seems overly enthusiastic -- if we're not optimizing, who cares?
>>
>> (When we zap TYHPE_METHODS we currently set it to error_mark_node, if it
>> was non-null, so that this above check will work).

> As a result gdb was unable to do an inferior call to its the object's
> methods.

Right, I realize I failed to mention gdb in the email.  To be clear, what the 
snippet does is NEVER put record types in registers, when not optimizing.

nathan
diff mbox

Patch

Index: gcc/function.c
===================================================================
--- gcc/function.c	(revision 250160)
+++ gcc/function.c	(working copy)
@@ -2218,20 +2218,11 @@  use_register_for_decl (const_tree decl)
   if (!DECL_REGISTER (decl))
     return false;
 
-  switch (TREE_CODE (TREE_TYPE (decl)))
-    {
-    case RECORD_TYPE:
-    case UNION_TYPE:
-    case QUAL_UNION_TYPE:
-      /* When not optimizing, disregard register keyword for variables with
-	 types containing methods, otherwise the methods won't be callable
-	 from the debugger.  */
-      if (TYPE_METHODS (TYPE_MAIN_VARIANT (TREE_TYPE (decl))))
-	return false;
-      break;
-    default:
-      break;
-    }
+  /* When not optimizing, disregard register keyword for types that
+     could have methods, otherwise the methods won't be callable from
+     the debugger.  */
+  if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl)))
+    return false;
 
   return true;
 }