diff mbox

[PR49888,VTA] don't keep VALUEs bound to modified MEMs

Message ID ory5o1d04j.fsf@livre.localdomain
State New
Headers show

Commit Message

Alexandre Oliva June 5, 2012, 7:33 p.m. UTC
On May 23, 2012, Jakub Jelinek <jakub@redhat.com> wrote:

> On Wed, May 23, 2012 at 06:27:21AM -0300, Alexandre Oliva wrote:
>> +	  for (loc = var->var_part[0].loc_chain; loc; loc = loc->next)
>> +	    if (GET_CODE (loc->loc) == MEM
>> +		&& !nonoverlapping_memrefs_p (loc->loc, mloc, false))

> Isn't nonoverlapping_memrefs_p predicate too conservative?
> cselib.c uses canon_true_dependence to decide what should be invalidated.

Yeah, I guess that should do.  I've finally managed to analyze the
effects of using canon_true_dependence on debug info, and it does seem
to produce reasonable results:

before after
= entry value count =
 33005  35700 i686/cc1plus
    99    116 i686/libgcc_s.so
   216    239 i686/libstdc++.so
 99902 104390 amd64/cc1plus
   308    319 amd64/libgcc_s.so
  8819   8864 amd64/libstdc++.so

= call site value count =
519877 514591 i686/cc1plus
   406    403 i686/libgcc_s.so
 10284  10121 i686/libstdc++.so
518401 518220 amd64/cc1plus
   341    341 amd64/libgcc_s.so
 11309  11261 amd64/libstdc++.so

loc info coverage             (before | after)

i686/cc1plus:
cov%    samples cumul                   cov%    samples cumul
0.0     155345/28%      155345/28%    | 0.0     155561/29%      155561/29%
0..5    6606/1% 161951/30%            | 0..5    7969/1% 163530/30%
6..10   5984/1% 167935/31%            | 6..10   6336/1% 169866/31%
11..15  4823/0% 172758/32%            | 11..15  5117/0% 174983/32%
16..20  6262/1% 179020/33%            | 16..20  6677/1% 181660/33%
21..25  5259/0% 184279/34%            | 21..25  5688/1% 187348/34%
26..30  5149/0% 189428/35%            | 26..30  5409/1% 192757/35%
31..35  4547/0% 193975/36%            | 31..35  4868/0% 197625/36%
36..40  7204/1% 201179/37%            | 36..40  7524/1% 205149/38%
41..45  8343/1% 209522/39%            | 41..45  8656/1% 213805/39%
46..50  8744/1% 218266/40%            | 46..50  9252/1% 223057/41%
51..55  5806/1% 224072/41%            | 51..55  6023/1% 229080/42%
56..60  6834/1% 230906/43%            | 56..60  7072/1% 236152/44%
61..65  5391/1% 236297/44%            | 61..65  5554/1% 241706/45%
66..70  9269/1% 245566/45%            | 66..70  9327/1% 251033/46%
71..75  6249/1% 251815/46%            | 71..75  6309/1% 257342/47%
76..80  8871/1% 260686/48%            | 76..80  8905/1% 266247/49%
81..85  8775/1% 269461/50%            | 81..85  8786/1% 275033/51%
86..90  13323/2%        282784/52%    | 86..90  13286/2%        288319/53%
91..95  21279/3%        304063/56%    | 91..95  20947/3%        309266/57%
96..99  21323/3%        325386/60%    | 96..99  20247/3%        329513/61%
100     211312/39%      536698/100%   | 100     206704/38%      536217/100%

i686/libgcc_s.so:
cov%    samples cumul                   cov%    samples cumul
0.0     511/21% 511/21%               | 0.0     512/21% 512/21%
0..5    44/1%   555/23%               | 0..5    67/2%   579/24%
6..10   45/1%   600/25%               | 6..10   41/1%   620/26%
11..15  35/1%   635/26%               | 11..15  37/1%   657/27%
16..20  28/1%   663/27%               | 16..20  29/1%   686/29%
21..25  32/1%   695/29%               | 21..25  32/1%   718/30%
26..30  40/1%   735/31%               | 26..30  41/1%   759/32%
31..35  32/1%   767/32%               | 31..35  34/1%   793/33%
36..40  29/1%   796/33%               | 36..40  33/1%   826/34%
41..45  42/1%   838/35%               | 41..45  44/1%   870/36%
46..50  47/1%   885/37%               | 46..50  56/2%   926/39%
51..55  33/1%   918/38%               | 51..55  35/1%   961/40%
56..60  45/1%   963/40%               | 56..60  48/2%   1009/42%
61..65  44/1%   1007/42%              | 61..65  43/1%   1052/44%
66..70  64/2%   1071/45%              | 66..70  68/2%   1120/47%
71..75  45/1%   1116/47%              | 71..75  45/1%   1165/49%
76..80  67/2%   1183/49%              | 76..80  69/2%   1234/52%
81..85  76/3%   1259/53%              | 81..85  76/3%   1310/55%
86..90  131/5%  1390/58%              | 86..90  119/5%  1429/60%
91..95  83/3%   1473/62%              | 91..95  81/3%   1510/63%
96..99  54/2%   1527/64%              | 96..99  49/2%   1559/66%
100     842/35% 2369/100%             | 100     802/33% 2361/100%

i686/libstdc++.so
cov%    samples cumul                   cov%    samples cumul
0.0     12708/37%       12708/37%     | 0.0     12737/37%       12737/37%
0..5    125/0%  12833/38%             | 0..5    263/0%  13000/38%
6..10   167/0%  13000/38%             | 6..10   201/0%  13201/39%
11..15  125/0%  13125/39%             | 11..15  157/0%  13358/39%
16..20  197/0%  13322/39%             | 16..20  216/0%  13574/40%
21..25  169/0%  13491/40%             | 21..25  194/0%  13768/40%
26..30  120/0%  13611/40%             | 26..30  155/0%  13923/41%
31..35  179/0%  13790/41%             | 31..35  188/0%  14111/41%
36..40  238/0%  14028/41%             | 36..40  257/0%  14368/42%
41..45  226/0%  14254/42%             | 41..45  266/0%  14634/43%
46..50  258/0%  14512/43%             | 46..50  270/0%  14904/44%
51..55  176/0%  14688/43%             | 51..55  199/0%  15103/44%
56..60  349/1%  15037/44%             | 56..60  362/1%  15465/46%
61..65  286/0%  15323/45%             | 61..65  288/0%  15753/46%
66..70  259/0%  15582/46%             | 66..70  260/0%  16013/47%
71..75  404/1%  15986/47%             | 71..75  416/1%  16429/48%
76..80  413/1%  16399/48%             | 76..80  403/1%  16832/50%
81..85  621/1%  17020/50%             | 81..85  617/1%  17449/51%
86..90  788/2%  17808/52%             | 86..90  733/2%  18182/54%
91..95  833/2%  18641/55%             | 91..95  774/2%  18956/56%
96..99  537/1%  19178/57%             | 96..99  495/1%  19451/57%
100     14426/42%       33604/100%    | 100     14148/42%       33599/100%


amd64/cc1plus:
cov%    samples cumul                   cov%    samples cumul
0.0     160910/31%      160910/31%    | 0.0     161076/31%      161076/31%
0..5    6266/1% 167176/32%            | 0..5    6543/1% 167619/32%
6..10   5484/1% 172660/33%            | 6..10   5615/1% 173234/33%
11..15  4874/0% 177534/34%            | 11..15  4989/0% 178223/34%
16..20  5001/0% 182535/35%            | 16..20  5108/0% 183331/35%
21..25  5383/1% 187918/36%            | 21..25  5458/1% 188789/36%
26..30  4182/0% 192100/37%            | 26..30  4286/0% 193075/37%
31..35  4731/0% 196831/38%            | 31..35  4814/0% 197889/38%
36..40  6995/1% 203826/39%            | 36..40  7068/1% 204957/40%
41..45  7749/1% 211575/41%            | 41..45  7814/1% 212771/41%
46..50  8686/1% 220261/42%            | 46..50  8788/1% 221559/43%
51..55  7650/1% 227911/44%            | 51..55  7728/1% 229287/44%
56..60  6394/1% 234305/45%            | 56..60  6457/1% 235744/46%
61..65  5629/1% 239934/46%            | 61..65  5685/1% 241429/47%
66..70  7371/1% 247305/48%            | 66..70  7448/1% 248877/48%
71..75  8137/1% 255442/49%            | 71..75  8162/1% 257039/50%
76..80  19364/3%        274806/53%    | 76..80  19363/3%        276402/54%
81..85  12056/2%        286862/55%    | 81..85  12024/2%        288426/56%
86..90  15509/3%        302371/58%    | 86..90  15431/3%        303857/59%
91..95  17138/3%        319509/62%    | 91..95  16897/3%        320754/62%
96..99  17654/3%        337163/65%    | 96..99  17034/3%        337788/66%
100     175723/34%      512886/100%   | 100     173852/33%      511640/100%

i686/libgcc_s.so:
cov%    samples cumul                   cov%    samples cumul
0.0     450/23% 450/23%                 0.0     450/23% 450/23%
0..5    46/2%   496/26%               | 0..5    47/2%   497/26%
6..10   29/1%   525/27%               | 6..10   30/1%   527/27%
11..15  33/1%   558/29%               | 11..15  34/1%   561/29%
16..20  32/1%   590/31%               | 16..20  33/1%   594/31%
21..25  31/1%   621/32%               | 21..25  31/1%   625/32%
26..30  20/1%   641/33%               | 26..30  20/1%   645/34%
31..35  24/1%   665/34%               | 31..35  24/1%   669/35%
36..40  39/2%   704/37%               | 36..40  41/2%   710/37%
41..45  53/2%   757/39%               | 41..45  52/2%   762/40%
46..50  25/1%   782/41%               | 46..50  25/1%   787/41%
51..55  32/1%   814/42%               | 51..55  32/1%   819/43%
56..60  40/2%   854/44%               | 56..60  40/2%   859/45%
61..65  42/2%   896/47%               | 61..65  43/2%   902/47%
66..70  55/2%   951/50%               | 66..70  54/2%   956/50%
71..75  69/3%   1020/53%              | 71..75  69/3%   1025/54%
76..80  41/2%   1061/55%              | 76..80  43/2%   1068/56%
81..85  33/1%   1094/57%              | 81..85  32/1%   1100/57%
86..90  74/3%   1168/61%              | 86..90  73/3%   1173/61%
91..95  57/2%   1225/64%              | 91..95  56/2%   1229/64%
96..99  45/2%   1270/66%              | 96..99  44/2%   1273/67%
100     632/33% 1902/100%             | 100     624/32% 1897/100%

amd64/libstdc++.so
cov%    samples cumul                   cov%    samples cumul
0.0     10565/36%       10565/36%     | 0.0     10594/36%       10594/36%
0..5    121/0%  10686/36%             | 0..5    141/0%  10735/36%
6..10   158/0%  10844/37%             | 6..10   187/0%  10922/37%
11..15  164/0%  11008/37%             | 11..15  186/0%  11108/37%
16..20  234/0%  11242/38%             | 16..20  237/0%  11345/38%
21..25  236/0%  11478/39%             | 21..25  239/0%  11584/39%
26..30  206/0%  11684/39%             | 26..30  212/0%  11796/40%
31..35  273/0%  11957/40%             | 31..35  286/0%  12082/41%
36..40  375/1%  12332/42%             | 36..40  376/1%  12458/42%
41..45  286/0%  12618/43%             | 41..45  285/0%  12743/43%
46..50  422/1%  13040/44%             | 46..50  419/1%  13162/44%
51..55  196/0%  13236/45%             | 51..55  193/0%  13355/45%
56..60  292/0%  13528/46%             | 56..60  303/1%  13658/46%
61..65  429/1%  13957/47%             | 61..65  431/1%  14089/48%
66..70  365/1%  14322/48%             | 66..70  373/1%  14462/49%
71..75  375/1%  14697/50%             | 71..75  378/1%  14840/50%
76..80  652/2%  15349/52%             | 76..80  650/2%  15490/52%
81..85  817/2%  16166/55%             | 81..85  798/2%  16288/55%
86..90  787/2%  16953/57%             | 86..90  780/2%  17068/58%
91..95  1090/3% 18043/61%             | 91..95  1076/3% 18144/61%
96..99  570/1%  18613/63%             | 96..99  562/1%  18706/63%
100     10683/36%       29296/100%    | 100     10565/36%       29271/100%

This patch was regstrapped along with the patch for PR47624 (ping
<http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01320.html>) on
x86_64-linux-gnu and i686-linux-gnu.  Ok to install?

Comments

Richard Henderson June 12, 2012, 8:42 p.m. UTC | #1
On 2012-06-05 12:33, Alexandre Oliva wrote:
> for  gcc/ChangeLog
> from  Alexandre Oliva  <aoliva@redhat.com>
> 
> 	PR debug/49888
> 	* var-tracking.c: Include alias.h.
> 	(overlapping_mems): New struct.
> 	(drop_overlapping_mem_locs): New.
> 	(clobber_overlapping_mems): New.
> 	(var_mem_delete_and_set, var_mem_delete): Call it.
> 	(val_bind): Likewise, but only if modified.
> 	(compute_bb_dataflow, emit_notes_in_bb): Call it on MEMs.
> 	* Makefile.in (var-tracking.o): Depend in $(ALIAS_H).
> 	
> for  gcc/testsuite/ChangeLog
> from  Alexandre Oliva  <aoliva@redhat.com>
> 
> 	PR debug/49888
> 	* gcc.dg/guality/pr49888.c: New.

Ok.


r~
H.J. Lu June 14, 2012, 2:43 p.m. UTC | #2
On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson <rth@redhat.com> wrote:
> On 2012-06-05 12:33, Alexandre Oliva wrote:
>> for  gcc/ChangeLog
>> from  Alexandre Oliva  <aoliva@redhat.com>
>>
>>       PR debug/49888
>>       * var-tracking.c: Include alias.h.
>>       (overlapping_mems): New struct.
>>       (drop_overlapping_mem_locs): New.
>>       (clobber_overlapping_mems): New.
>>       (var_mem_delete_and_set, var_mem_delete): Call it.
>>       (val_bind): Likewise, but only if modified.
>>       (compute_bb_dataflow, emit_notes_in_bb): Call it on MEMs.
>>       * Makefile.in (var-tracking.o): Depend in $(ALIAS_H).
>>
>> for  gcc/testsuite/ChangeLog
>> from  Alexandre Oliva  <aoliva@redhat.com>
>>
>>       PR debug/49888
>>       * gcc.dg/guality/pr49888.c: New.
>
> Ok.
>
>

It caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671
Alexandre Oliva June 15, 2012, 10:21 p.m. UTC | #3
On Jun 14, 2012, "H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 2012-06-05 12:33, Alexandre Oliva wrote:
>>> for  gcc/ChangeLog
>>> from  Alexandre Oliva  <aoliva@redhat.com>
>>> 
>>>       PR debug/49888
>>>       * var-tracking.c: Include alias.h.
>>>       (overlapping_mems): New struct.
>>>       (drop_overlapping_mem_locs): New.
>>>       (clobber_overlapping_mems): New.
>>>       (var_mem_delete_and_set, var_mem_delete): Call it.
>>>       (val_bind): Likewise, but only if modified.
>>>       (compute_bb_dataflow, emit_notes_in_bb): Call it on MEMs.
>>>       * Makefile.in (var-tracking.o): Depend in $(ALIAS_H).
>>> 
>>> for  gcc/testsuite/ChangeLog
>>> from  Alexandre Oliva  <aoliva@redhat.com>
>>> 
>>>       PR debug/49888
>>>       * gcc.dg/guality/pr49888.c: New.
>> 
>> Ok.

> It caused:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671

I see a few of these failures myself.  They're in my test results.  I
guess I was so caught up in assessing the debug info quality changes
with this patch that I completely failed to look at the test results,
because they've been around for a while, and I have a few pristine-build
baselines in between.  Apologies for this mistake.

Anyway...  The problem is not too hard to understand, but it may be
somewhat hard to fix.  Basically, pushing registers to save them on the
stack implies writes that are currently thought to conflict with the
MEMs holding incoming arguments, and apparently there isn't enough
information in the cselib static table for us to realize the write
doesn't alias with any of the incoming arguments.

Using the dynamic tables during alias testing is one possibility I'm
looking into, but this won't be trivial and it could get expensive;
another, that has just occurred to me while composing this message, is
to use the cselib static table itself, for it *should* have enough info
for us to realize that argp and sp offset are related and, given proper
offsets, non-overlapping.

Now, neither approach is going to be an immediate fix.  Should I revert
the patch, or can we live with some debug info completeness regressions
for a bit?  I wouldn't mind reverting it, but I won't unless the broken
patch is actually causing trouble to any of us.

Again, sorry about the breakage.
H.J. Lu June 16, 2012, 8:10 p.m. UTC | #4
On Fri, Jun 15, 2012 at 3:21 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jun 14, 2012, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>
>> On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson <rth@redhat.com> wrote:
>>> On 2012-06-05 12:33, Alexandre Oliva wrote:
>>>> for  gcc/ChangeLog
>>>> from  Alexandre Oliva  <aoliva@redhat.com>
>>>>
>>>>       PR debug/49888
>>>>       * var-tracking.c: Include alias.h.
>>>>       (overlapping_mems): New struct.
>>>>       (drop_overlapping_mem_locs): New.
>>>>       (clobber_overlapping_mems): New.
>>>>       (var_mem_delete_and_set, var_mem_delete): Call it.
>>>>       (val_bind): Likewise, but only if modified.
>>>>       (compute_bb_dataflow, emit_notes_in_bb): Call it on MEMs.
>>>>       * Makefile.in (var-tracking.o): Depend in $(ALIAS_H).
>>>>
>>>> for  gcc/testsuite/ChangeLog
>>>> from  Alexandre Oliva  <aoliva@redhat.com>
>>>>
>>>>       PR debug/49888
>>>>       * gcc.dg/guality/pr49888.c: New.
>>>
>>> Ok.
>
>> It caused:
>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671
>
> I see a few of these failures myself.  They're in my test results.  I
> guess I was so caught up in assessing the debug info quality changes
> with this patch that I completely failed to look at the test results,
> because they've been around for a while, and I have a few pristine-build
> baselines in between.  Apologies for this mistake.
>
> Anyway...  The problem is not too hard to understand, but it may be
> somewhat hard to fix.  Basically, pushing registers to save them on the
> stack implies writes that are currently thought to conflict with the
> MEMs holding incoming arguments, and apparently there isn't enough
> information in the cselib static table for us to realize the write
> doesn't alias with any of the incoming arguments.
>
> Using the dynamic tables during alias testing is one possibility I'm
> looking into, but this won't be trivial and it could get expensive;
> another, that has just occurred to me while composing this message, is
> to use the cselib static table itself, for it *should* have enough info
> for us to realize that argp and sp offset are related and, given proper
> offsets, non-overlapping.
>
> Now, neither approach is going to be an immediate fix.  Should I revert
> the patch, or can we live with some debug info completeness regressions
> for a bit?  I wouldn't mind reverting it, but I won't unless the broken
> patch is actually causing trouble to any of us.
>

If I understand it correctly, the new approach fails to handle push
properly.  If it is true, I think the patch should be reverted.

Thanks.
diff mbox

Patch

for  gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	PR debug/49888
	* var-tracking.c: Include alias.h.
	(overlapping_mems): New struct.
	(drop_overlapping_mem_locs): New.
	(clobber_overlapping_mems): New.
	(var_mem_delete_and_set, var_mem_delete): Call it.
	(val_bind): Likewise, but only if modified.
	(compute_bb_dataflow, emit_notes_in_bb): Call it on MEMs.
	* Makefile.in (var-tracking.o): Depend in $(ALIAS_H).
	
for  gcc/testsuite/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	PR debug/49888
	* gcc.dg/guality/pr49888.c: New.

Index: gcc/var-tracking.c
===================================================================
--- gcc/var-tracking.c.orig	2012-06-05 03:03:47.154714459 -0300
+++ gcc/var-tracking.c	2012-06-05 12:50:57.724756717 -0300
@@ -115,6 +115,7 @@ 
 #include "pointer-set.h"
 #include "recog.h"
 #include "tm_p.h"
+#include "alias.h"
 
 /* var-tracking.c assumes that tree code with the same value as VALUE rtx code
    has no chance to appear in REG_EXPR/MEM_EXPRs and isn't a decl.
@@ -1954,6 +1955,111 @@  var_regno_delete (dataflow_set *set, int
   *reg = NULL;
 }
 
+/* Hold parameters for the hashtab traversal function
+   drop_overlapping_mem_locs, see below.  */
+
+struct overlapping_mems
+{
+  dataflow_set *set;
+  rtx loc, addr;
+};
+
+/* Remove all MEMs that overlap with COMS->LOC from the location list
+   of a hash table entry for a value.  COMS->ADDR must be a
+   canonicalized form of COMS->LOC's address, and COMS->LOC must be
+   canonicalized itself.  */
+
+static int
+drop_overlapping_mem_locs (void **slot, void *data)
+{
+  struct overlapping_mems *coms = (struct overlapping_mems *)data;
+  dataflow_set *set = coms->set;
+  rtx mloc = coms->loc, addr = coms->addr;
+  variable var = (variable) *slot;
+
+  if (var->onepart == ONEPART_VALUE)
+    {
+      location_chain loc, *locp;
+      bool changed = false;
+      rtx cur_loc;
+
+      gcc_assert (var->n_var_parts == 1);
+
+      if (shared_var_p (var, set->vars))
+	{
+	  for (loc = var->var_part[0].loc_chain; loc; loc = loc->next)
+	    if (GET_CODE (loc->loc) == MEM
+		&& canon_true_dependence (mloc, GET_MODE (mloc), addr,
+					  loc->loc, NULL))
+	      break;
+
+	  if (!loc)
+	    return 1;
+
+	  slot = unshare_variable (set, slot, var, VAR_INIT_STATUS_UNKNOWN);
+	  var = (variable)*slot;
+	  gcc_assert (var->n_var_parts == 1);
+	}
+
+      if (VAR_LOC_1PAUX (var))
+	cur_loc = VAR_LOC_FROM (var);
+      else
+	cur_loc = var->var_part[0].cur_loc;
+
+      for (locp = &var->var_part[0].loc_chain, loc = *locp;
+	   loc; loc = *locp)
+	{
+	  if (GET_CODE (loc->loc) != MEM
+	      || !canon_true_dependence (mloc, GET_MODE (mloc), addr,
+					 loc->loc, NULL))
+	    {
+	      locp = &loc->next;
+	      continue;
+	    }
+
+	  *locp = loc->next;
+	  /* If we have deleted the location which was last emitted
+	     we have to emit new location so add the variable to set
+	     of changed variables.  */
+	  if (cur_loc == loc->loc)
+	    {
+	      changed = true;
+	      var->var_part[0].cur_loc = NULL;
+	      if (VAR_LOC_1PAUX (var))
+		VAR_LOC_FROM (var) = NULL;
+	    }
+	  pool_free (loc_chain_pool, loc);
+	}
+
+      if (!var->var_part[0].loc_chain)
+	{
+	  var->n_var_parts--;
+	  changed = true;
+	}
+      if (changed)
+	variable_was_changed (var, set);
+    }
+
+  return 1;
+}
+
+/* Remove from SET all VALUE bindings to MEMs that overlap with LOC.  */
+
+static void
+clobber_overlapping_mems (dataflow_set *set, rtx loc)
+{
+  struct overlapping_mems coms;
+
+  coms.set = set;
+  coms.loc = canon_rtx (loc);
+  coms.addr = canon_rtx (get_addr (XEXP (loc, 0)));
+
+  set->traversed_vars = set->vars;
+  htab_traverse (shared_hash_htab (set->vars),
+		 drop_overlapping_mem_locs, &coms);
+  set->traversed_vars = NULL;
+}
+
 /* Set the location of DV, OFFSET as the MEM LOC.  */
 
 static void
@@ -1996,6 +2102,7 @@  var_mem_delete_and_set (dataflow_set *se
   tree decl = MEM_EXPR (loc);
   HOST_WIDE_INT offset = INT_MEM_OFFSET (loc);
 
+  clobber_overlapping_mems (set, loc);
   decl = var_debug_decl (decl);
 
   if (initialized == VAR_INIT_STATUS_UNKNOWN)
@@ -2016,6 +2123,7 @@  var_mem_delete (dataflow_set *set, rtx l
   tree decl = MEM_EXPR (loc);
   HOST_WIDE_INT offset = INT_MEM_OFFSET (loc);
 
+  clobber_overlapping_mems (set, loc);
   decl = var_debug_decl (decl);
   if (clobber)
     clobber_variable_part (set, NULL, dv_from_decl (decl), offset, NULL);
@@ -2059,6 +2167,9 @@  val_bind (dataflow_set *set, rtx val, rt
     {
       struct elt_loc_list *l = CSELIB_VAL_PTR (val)->locs;
 
+      if (modified)
+	clobber_overlapping_mems (set, loc);
+
       if (l && GET_CODE (l->loc) == VALUE)
 	l = canonical_cselib_val (CSELIB_VAL_PTR (l->loc))->locs;
 
@@ -6371,6 +6482,8 @@  compute_bb_dataflow (basic_block bb)
 		}
 	      else if (REG_P (uloc))
 		var_regno_delete (out, REGNO (uloc));
+	      else if (MEM_P (uloc))
+		clobber_overlapping_mems (out, uloc);
 
 	      val_store (out, val, dstv, insn, true);
 	    }
@@ -8870,6 +8983,8 @@  emit_notes_in_bb (basic_block bb, datafl
 		}
 	      else if (REG_P (uloc))
 		var_regno_delete (set, REGNO (uloc));
+	      else if (MEM_P (uloc))
+		clobber_overlapping_mems (set, uloc);
 
 	      val_store (set, val, dstv, insn, true);
 
Index: gcc/Makefile.in
===================================================================
--- gcc/Makefile.in.orig	2012-06-05 03:02:32.904609594 -0300
+++ gcc/Makefile.in	2012-06-05 12:54:21.000000000 -0300
@@ -3130,8 +3130,8 @@  var-tracking.o : var-tracking.c $(CONFIG
    $(RTL_H) $(TREE_H) hard-reg-set.h insn-config.h reload.h $(FLAGS_H) \
    $(BASIC_BLOCK_H) bitmap.h alloc-pool.h $(FIBHEAP_H) $(HASHTAB_H) \
    $(REGS_H) $(EXPR_H) $(TIMEVAR_H) $(TREE_PASS_H) $(TREE_FLOW_H) \
-   cselib.h $(TARGET_H) $(DIAGNOSTIC_CORE_H) $(PARAMS_H) $(DIAGNOSTIC_H) pointer-set.h \
-   $(RECOG_H) $(TM_P_H) $(TREE_PRETTY_PRINT_H)
+   cselib.h $(TARGET_H) $(DIAGNOSTIC_CORE_H) $(PARAMS_H) $(DIAGNOSTIC_H) \
+   pointer-set.h $(RECOG_H) $(TM_P_H) $(TREE_PRETTY_PRINT_H) $(ALIAS_H)
 profile.o : profile.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) \
    $(TREE_H) $(FLAGS_H) $(REGS_H) $(EXPR_H) $(FUNCTION_H) $(BASIC_BLOCK_H) \
    $(DIAGNOSTIC_CORE_H) $(COVERAGE_H) $(TREE_FLOW_H) value-prof.h cfghooks.h \
Index: gcc/testsuite/gcc.dg/guality/pr49888.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gcc/testsuite/gcc.dg/guality/pr49888.c	2012-06-05 12:50:57.878744571 -0300
@@ -0,0 +1,25 @@ 
+/* PR debug/49888 */
+/* { dg-do run } */
+/* { dg-options "-g" } */
+
+static int v;
+
+static void __attribute__((noinline, noclone))
+f (int *p)
+{
+  int c = *p;
+  v = c;
+  *p = 1; /* { dg-final { gdb-test 12 "c" "0" } } */
+  /* c may very well be optimized out at this point, so we test !c,
+     which will evaluate to the expected value.  We just want to make
+     sure it doesn't remain bound to *p as it did before, in which
+     case !c would evaluate to 0.  */
+  v = 0; /* { dg-final { gdb-test 17 "!c" "1" } } */
+}
+int
+main ()
+{
+  int a = 0;
+  f (&a);
+  return 0;
+}