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
18 matches
Mail list logo
