On 06/01/2011 07:25 AM, Jakub Jelinek wrote:
> 2011-06-01 Jakub Jelinek
>
> * var-tracking.c (create_entry_value): New function.
> (vt_add_function_parameter): Use it.
Ok.
r~
On Mon, Mar 28, 2011 at 10:50:14AM -0700, Richard Henderson wrote:
> > I will look into creating helper inlines to reduce code duplication.
>
> Please. You can do this as a follow-up if you prefer.
Sorry it took so long, here it is. Bootstrapped/regtested on x86_64-linux
and i686-linux, makes z
On 03/28/2011 10:32 AM, Jakub Jelinek wrote:
> Say vt_add_function_parameter is called for first parameter in %rdi,
> cselib_lookup_from_insn gives us VALUE 2:2 for it. We add
> (entry_value:DI (reg:DI %rdi)) to list of locations for that VALUE.
> The second cselib_lookup_from_insn gives us VALUE
On Mon, Mar 28, 2011 at 09:58:38AM -0700, Richard Henderson wrote:
> > * 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 defini
On 03/20/2011 05:57 AM, Jakub Jelinek wrote:
> * cfgexpand.c (expand_debug_expr) : 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.
>
Hi!
This patch fixes a few problems:
1) on arm bootstrap fails, because expansion creates ENTRY_VALUE
of a MEM with virtual reg address, which then is changed for
ap + constant and dwarf2out doesn't expect that.
As in most passes ENTRY_VALUE is treated like a black box,
we shouldn't ac
