On Jun 21, 2012, Alexandre Oliva wrote:
> Here's one more patch that addresses a problem I found out while
> investigating the PR53671 regressions: rather than recording incoming
> stack args as MEMs with non-VALUE expressions, it's more consistent (and
> less surprising) if we emit them as VALUE
On Jun 21, 2012, Alexandre Oliva wrote:
> for gcc/ChangeLog
> from Alexandre Oliva
> PR debug/53671
> PR debug/49888
> * alias.c (memrefs_conflict_p): Improve handling of AND for
> alignment.
There was a thinko in this patch. We can't move the offset by more
On Jun 27, 2012, Richard Henderson wrote:
> On 06/26/2012 01:54 PM, Alexandre Oliva wrote:
>> + track_stack_pointer (dst, src1, src2);
> Why does this function return a value then?
During testing, I used an assert on the return value to catch cases that
couldn't be handled. The comments befor
On 06/26/2012 01:54 PM, Alexandre Oliva wrote:
> + track_stack_pointer (dst, src1, src2);
Why does this function return a value then?
r~
On Jun 14, 2012, "H.J. Lu" wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671
These two patches cure the two remaining problems.
Basically, we have a problem of tracking equivalent FP-relative
addresses across basic blocks when SP varies. Once we lost track of SP,
pushing an argument f
On Thu, Jun 21, 2012 at 10:58:05PM -0300, Alexandre Oliva wrote:
> for gcc/ChangeLog
> from Alexandre Oliva
>
> * var-tracking.c (vt_add_function_parameter): Use a preserved
> VALUE for the MEM address of an incoming parameter.
Okay.
Jakub
Here's one more patch that addresses a problem I found out while
investigating the PR53671 regressions: rather than recording incoming
stack args as MEMs with non-VALUE expressions, it's more consistent (and
less surprising) if we emit them as VALUE expressions, like other MEMs.
Regstrapped on x86
On Jun 20, 2012, Richard Guenther wrote:
> I have a question on the pre-existing condition
> - if (GET_CODE (y) == AND || ysize < -INTVAL (XEXP (x, 1)))
> xsize = -1;
> so if this condition is not true then we simply strip off the AND of X and
> do not adjust xsize at all? Likewis
On Wed, Jun 20, 2012 at 12:52:12AM -0300, Alexandre Oliva wrote:
> On Jun 16, 2012, "H.J. Lu" wrote:
> from Alexandre Oliva
>
> PR debug/53671
> PR debug/49888
> * alias.c (memrefs_conflict_p): Improve handling of AND for
> alignment.
> from Alexandre Oliva
>
>
On Wed, Jun 20, 2012 at 5:52 AM, Alexandre Oliva wrote:
> On Jun 16, 2012, "H.J. Lu" wrote:
>
>> If I understand it correctly, the new approach fails to handle push
>> properly.
>
> It's actually cselib that didn't deal with push properly, so it thinks
> incoming stack arguments may be clobbered
On Jun 16, 2012, "H.J. Lu" wrote:
> If I understand it correctly, the new approach fails to handle push
> properly.
It's actually cselib that didn't deal with push properly, so it thinks
incoming stack arguments may be clobbered by them. But that's not the
whole story, unfortunately. I still d
On Fri, Jun 15, 2012 at 3:21 PM, Alexandre Oliva wrote:
> On Jun 14, 2012, "H.J. Lu" wrote:
>
>> On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson wrote:
>>> On 2012-06-05 12:33, Alexandre Oliva wrote:
for gcc/ChangeLog
from Alexandre Oliva
PR debug/49888
On Jun 14, 2012, "H.J. Lu" wrote:
> On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson wrote:
>> On 2012-06-05 12:33, Alexandre Oliva wrote:
>>> for gcc/ChangeLog
>>> from Alexandre Oliva
>>>
>>> PR debug/49888
>>> * var-tracking.c: Include alias.h.
>>> (overlapping_mems):
On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson wrote:
> On 2012-06-05 12:33, Alexandre Oliva wrote:
>> for gcc/ChangeLog
>> from Alexandre Oliva
>>
>> PR debug/49888
>> * var-tracking.c: Include alias.h.
>> (overlapping_mems): New struct.
>> (drop_overlapping_mem_lo
On 2012-06-05 12:33, Alexandre Oliva wrote:
> for gcc/ChangeLog
> from Alexandre Oliva
>
> PR debug/49888
> * var-tracking.c: Include alias.h.
> (overlapping_mems): New struct.
> (drop_overlapping_mem_locs): New.
> (clobber_overlapping_mems): New.
> (var_mem
On May 23, 2012, Jakub Jelinek 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
On Wed, May 23, 2012 at 12:13 PM, Jakub Jelinek wrote:
> On Wed, May 23, 2012 at 06:27:21AM -0300, Alexandre Oliva wrote:
>> +static int
>> +drop_overlapping_mem_locs (void **slot, void *data)
>> +{
>> + struct overlapping_mems *coms = (struct overlapping_mems *)data;
>> + dataflow_set *set = co
On Wed, May 23, 2012 at 06:27:21AM -0300, Alexandre Oliva wrote:
> +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;
> + variable var = (variab
Nothing in var-tracking was prepared to drop MEMs from bindings upon
writes that might modify the MEM contents. That was correct, back when
it was variables (rather than values) that were bound to MEMs, and we
wanted the binding to remain even if the value stored in the variables
changed.
VTA cha
19 matches
Mail list logo
