Richard Sandiford writes:
> gcc/
> * dwarf2out.c (dw_loc_list_node): Add resolved_addr and replaced.
> (cached_dw_loc_list_def): New structure.
> (cached_dw_loc_list): New typedef.
> (cached_dw_loc_list_table): New variable.
> (cached_dw_loc_list_table_hash): New func
On 05.03.2011 15:37, Richard Sandiford wrote:
> Jakub Jelinek writes:
>> On Fri, Mar 04, 2011 at 01:56:55PM +, Richard Sandiford wrote:
>>> * dwarf2out.c (dw_loc_list_node): Add resolved_addr and replaced.
>>> (cached_dw_loc_list_def): New structure.
>>> (cached_dw_loc_list): New t
Jakub Jelinek writes:
> On Fri, Mar 04, 2011 at 01:56:55PM +, Richard Sandiford wrote:
>> * dwarf2out.c (dw_loc_list_node): Add resolved_addr and replaced.
>> (cached_dw_loc_list_def): New structure.
>> (cached_dw_loc_list): New typedef.
>> (cached_dw_loc_list_table): New v
Jakub Jelinek writes:
> On Fri, Mar 04, 2011 at 04:00:06PM +0100, Richard Guenther wrote:
>> But then location lists for those variables depend on the function context
>> and cannot be shared for different callers. Am I missing something?
>
> Sure, they can't be shared between different functions
On Fri, Mar 04, 2011 at 01:56:55PM +, Richard Sandiford wrote:
> * dwarf2out.c (dw_loc_list_node): Add resolved_addr and replaced.
> (cached_dw_loc_list_def): New structure.
> (cached_dw_loc_list): New typedef.
> (cached_dw_loc_list_table): New variable.
> (cached_
On Fri, Mar 4, 2011 at 4:10 PM, Jakub Jelinek wrote:
> On Fri, Mar 04, 2011 at 04:00:06PM +0100, Richard Guenther wrote:
>> But then location lists for those variables depend on the function context
>> and cannot be shared for different callers. Am I missing something?
>
> Sure, they can't be sha
On Fri, Mar 04, 2011 at 04:00:06PM +0100, Richard Guenther wrote:
> But then location lists for those variables depend on the function context
> and cannot be shared for different callers. Am I missing something?
Sure, they can't be shared between different functions. If Richard's patch
does tha
On Fri, Mar 4, 2011 at 3:49 PM, Jakub Jelinek wrote:
> On Fri, Mar 04, 2011 at 03:30:34PM +0100, Richard Guenther wrote:
>> On Fri, Mar 4, 2011 at 2:56 PM, Richard Sandiford
>> > Jakub confirms that this indeed the intended behaviour, and I haven't
>> > seen any problem with the output.
>>
>> Hm,
On Fri, Mar 04, 2011 at 03:30:34PM +0100, Richard Guenther wrote:
> On Fri, Mar 4, 2011 at 2:56 PM, Richard Sandiford
> > Jakub confirms that this indeed the intended behaviour, and I haven't
> > seen any problem with the output.
>
> Hm, but isn't it incorrect debug info? I would have expected th
Richard Guenther writes:
> On Fri, Mar 4, 2011 at 2:56 PM, Richard Sandiford
> wrote:
>> Suppose we have a function F that is inlined several times. Suppose too
>> that F has a local variable X, and that no "real" (as opposed to debug)
>> references to X remain after pre-inlining optimisations.
On Fri, Mar 4, 2011 at 2:56 PM, Richard Sandiford
wrote:
> Suppose we have a function F that is inlined several times. Suppose too
> that F has a local variable X, and that no "real" (as opposed to debug)
> references to X remain after pre-inlining optimisations. In this case,
> we will add X to
Suppose we have a function F that is inlined several times. Suppose too
that F has a local variable X, and that no "real" (as opposed to debug)
references to X remain after pre-inlining optimisations. In this case,
we will add X to BLOCK_NONLOCALIZED_VARS rather than duplicate it each
time F is i
12 matches
Mail list logo
