Re: Delete dead (?) code in expand_expr_real_2
On Tue, Mar 6, 2012 at 12:51 AM, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote: I found a weird piece of code that was added by kenner in a really early revision. It checks for VAR_DECLs with frame or stack pointers as DECL_RTL, and the comment in front of it mentions strength reduction. Presumably this was for the old loop optimizer? I can't think of anything that would require this in a modern version of gcc. I think such a VAR_DECL would occur in cases of alloca. I don't understand the comment about strength reduction (despite obviously having written it!) because the old loop optimizer ran on RTL and this is talking about trees. My guess is that this isn't dead. I don't see how a VAR_DECL can ever get a DECL_RTL equal to one of the mentioned regs. The patch is ok if a gcc_unreachable () inside the if () passes bootstrap. Thanks, Richard.
Re: Delete dead (?) code in expand_expr_real_2
I don't see how a VAR_DECL can ever get a DECL_RTL equal to one of the mentioned regs. Doesn't that happen when you have a local variable that's a variable-sized object? What would have changed that would cause it to no longer happen? This is tree-level stuff, not RTL. The patch is ok if a gcc_unreachable () inside the if () passes bootstrap. We have no such in most of the compiler, so I don't think that's a good test. There may be some in Ada, but I'm not sure. I'd suggest running it over all the test suites as well.
Re: Delete dead (?) code in expand_expr_real_2
On Tue, Mar 06, 2012 at 06:17:52AM -0500, Richard Kenner wrote: I don't see how a VAR_DECL can ever get a DECL_RTL equal to one of the mentioned regs. Doesn't that happen when you have a local variable that's a variable-sized object? What would have changed that would cause it to no longer happen? This is tree-level stuff, not RTL. VLA VAR_DECLs have just DECL_HAS_VALUE_EXPR_P set and DECL_VALUE_EXPR being INDIRECT_REF (or MEM_REF now?) dereferencing some DECL_ARTIFICIAL VAR_DECL that is initialized from alloca builtin.So the VLA VAR_DECLs don't have any DECL_RTL at all (kept for debug info purposes only), and the artificial pointer to it will just have as DECL_RTL some pseudo or so. Jakub
Re: Delete dead (?) code in expand_expr_real_2
VLA VAR_DECLs have just DECL_HAS_VALUE_EXPR_P set and DECL_VALUE_EXPR being INDIRECT_REF (or MEM_REF now?) dereferencing some DECL_ARTIFICIAL VAR_DECL that is initialized from alloca builtin.So the VLA VAR_DECLs don't have any DECL_RTL at all (kept for debug info purposes only), and the artificial pointer to it will just have as DECL_RTL some pseudo or so. That change may well have killed this code, then.
Delete dead (?) code in expand_expr_real_2
I found a weird piece of code that was added by kenner in a really early
revision. It checks for VAR_DECLs with frame or stack pointers as
DECL_RTL, and the comment in front of it mentions strength reduction.
Presumably this was for the old loop optimizer? I can't think of
anything that would require this in a modern version of gcc.
Bootstrapped and tested on i686-linux; no changes in code generation on
any of my test files. Ok?
Bernd
* expr.c (expand_expr_real_2) [PLUS_EXPR]: Delete code dealing with
VAR_DECLs of frame or stack pointers.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 184790)
+++ gcc/expr.c (working copy)
@@ -8040,30 +8040,6 @@ expand_expr_real_2 (sepops ops, rtx targ
fold_convert_loc (loc, ssizetype,
treeop1));
case PLUS_EXPR:
- /* If we are adding a constant, a VAR_DECL that is sp, fp, or ap, and
-something else, make sure we add the register to the constant and
-then to the other thing. This case can occur during strength
-reduction and doing it this way will produce better code if the
-frame pointer or argument pointer is eliminated.
-
-fold-const.c will ensure that the constant is always in the inner
-PLUS_EXPR, so the only case we need to do anything about is if
-sp, ap, or fp is our second argument, in which case we must swap
-the innermost first argument and our second argument. */
-
- if (TREE_CODE (treeop0) == PLUS_EXPR
- TREE_CODE (TREE_OPERAND (treeop0, 1)) == INTEGER_CST
- TREE_CODE (treeop1) == VAR_DECL
- (DECL_RTL (treeop1) == frame_pointer_rtx
- || DECL_RTL (treeop1) == stack_pointer_rtx
- || DECL_RTL (treeop1) == arg_pointer_rtx))
- {
- tree t = treeop1;
-
- treeop1 = TREE_OPERAND (treeop0, 0);
- TREE_OPERAND (treeop0, 0) = t;
- }
-
/* If the result is to be ptr_mode and we are adding an integer to
something, we might be forming a constant. So try to use
plus_constant. If it produces a sum and we can't accept it,
Re: Delete dead (?) code in expand_expr_real_2
I found a weird piece of code that was added by kenner in a really early revision. It checks for VAR_DECLs with frame or stack pointers as DECL_RTL, and the comment in front of it mentions strength reduction. Presumably this was for the old loop optimizer? I can't think of anything that would require this in a modern version of gcc. I think such a VAR_DECL would occur in cases of alloca. I don't understand the comment about strength reduction (despite obviously having written it!) because the old loop optimizer ran on RTL and this is talking about trees. My guess is that this isn't dead.
