On Thu, Jan 17, 2013 at 06:56:40PM -0200, Alexandre Oliva wrote:
> From: Alexandre Oliva
>
> for gcc/ChangeLog
>
> PR debug/54114
> PR debug/54402
> PR debug/49888
> * var-tracking.c (negative_power_of_two_p): New.
> (global_get_addr_cache, local_get_addr_cache): N
On Jan 16, 2013, Jakub Jelinek wrote:
> for i686-linux tree-ssa-pre.o is different, and
> for x86_64-linux go/export.o is different.
I looked into the latter first, and that revealed a few major bugs:
1. I'd failed to fully implement what I'd planned. The canonicalization
function would still
On Wed, Jan 16, 2013 at 11:25:46AM -0200, Alexandre Oliva wrote:
> > Also, what effects (if any) does the patch have on the
> > .debug_info/.debug_loc size and coverage?
>
> It shouldn't have any, since it's just caching results that would have
> been recomputed over and over. However, there's a
On Wed, Jan 16, 2013 at 11:25:46AM -0200, Alexandre Oliva wrote:
> > Can you safely cache the canon addresses already during vt_initialize
> > (when cselib_* is still processing new insns, cselib VALUEs contain
> > REGs and MEMs that are flushed at the end of processing the current bb
> > in vt_ini
On Jan 16, 2013, Jakub Jelinek wrote:
> On Wed, Jan 16, 2013 at 08:28:59AM -0200, Alexandre Oliva wrote:
>> PR49888 introduced clobber_overlapping_mems to detach VALUEs (and
>> variables bound to them) from MEMs as the MEMs are modified. This
>> turned out to be quite expensive, particularly the
On Wed, Jan 16, 2013 at 08:28:59AM -0200, Alexandre Oliva wrote:
> PR49888 introduced clobber_overlapping_mems to detach VALUEs (and
> variables bound to them) from MEMs as the MEMs are modified. This
> turned out to be quite expensive, particularly the computation of
> canonical addresses passed
