This is the mail archive of the gcc-patches@gcc.gnu.org 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] ENTRY_VALUE fixes (PR debug/48203)


On 03/20/2011 05:57 AM, Jakub Jelinek wrote:
> 	* cfgexpand.c (expand_debug_expr) <case SSA_NAME>: Only
> 	create ENTRY_VALUE if incoming or address of incoming's MEM
> 	is a hard REG.
> 	* dwarf2out.c (mem_loc_descriptor): Don't emit
> 	DW_OP_GNU_entry_value of DW_OP_fbreg.

Ok.

> 	* var-tracking.c (vt_add_function_parameter): Ensure cselib_lookup
> 	on ENTRY_VALUE is able to find the canonical parameter VALUE.

I don't really understand what's going on here.  Whatever it is, it
could definitely use some more commentary; there's almost nothing in
the surrounding context.  I also suggest pulling some of this out into
a new function.  You've got 2 exact copies here in the patch, and 2
more that are nearly the same already in the code.

> 	* cselib.c (rtx_equal_for_cselib_1) <case ENTRY_VALUE>: Use
> 	rtx_equal_p instead of rtx_equal_for_cselib_1 to compare
> 	ENTRY_VALUE_EXPs.

Ok.

> 	(cselib_hash_rtx) <case ENTRY_VALUE>: If ENTRY_VALUE_EXP
> 	is a REG_P or MEM_P with REG_P address, compute hash directly
> 	instead of calling cselib_hash_rtx on ENTRY_VALUE_EXP.

Why?

> 	(preserve_only_constants): Don't clear VALUES forwaring
> 	ENTRY_VALUE to some other VALUE.

Ok with a comment.  I guess the reasoning being that even though this
value isn't "constant", it's function invariant?


r~


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