This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR optimization/13653

On Thu, 2004-05-27 at 02:33, Eric Botcazou wrote:
> > It seems to me that if the object is being set inside a loop, then
> > it should never have had the unchanging bit set in the first place.
> > Can you track down how that is happening?
> It's maybe_set_unchanging:
>   /* We can set RTX_UNCHANGING_P from TREE_READONLY for decls whose
>      initialization is only executed once, or whose initializer always
>      has the same value.  Currently we simplify this to PARM_DECLs in the
>      first case, and decls with TREE_CONSTANT initializers in the second.
> */
>   if ((TREE_READONLY (t) && DECL_P (t)
>        && (TREE_STATIC (t) || ! AGGREGATE_TYPE_P (TREE_TYPE (t)))
>        && (TREE_CODE (t) == PARM_DECL
> 	   || DECL_INITIAL (t) == NULL_TREE
>       || TREE_CODE_CLASS (TREE_CODE (t)) == 'c')
>     RTX_UNCHANGING_P (ref) = 1;
> DECL_INITIAL is 0 here so the /u flag is set.
It might help me to see the RTL for the loop in question as well.
Presumably the object we care about has TREE_READONLY set?  But
it's value varies from one iteration to the next (seems to me that
if the value does not vary, then it could not have been a GIV).

> Note this note in loop_invariant_p:
>     case REG:
>       /* We used to check RTX_UNCHANGING_P (x) here, but that is invalid
> 	 since the reg might be set by initialization within the loop.  */
>       if ((x == frame_pointer_rtx || x == hard_frame_pointer_rtx
> 	   || x == arg_pointer_rtx || x == pic_offset_table_rtx)
> 	  && ! current_function_has_nonlocal_goto)
> 	return 1;
> My understanding is that RTX_UNCHANGING_P used to be enough to return 1, but 
> was subsequently recognized as not sufficient.
Right.  And presumably that's what's happening in this case -- ie, we
have a reg which is set by the initialization in a loop and we're
somehow determining that the initialization sequence looks like a GIV.
And we're doing this even though we've set TREE_READONLY on the
object.  Right?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]