On Tue, Nov 5, 2013 at 11:50 AM, Marc Glisse wrote:
> On Mon, 4 Nov 2013, Richard Biener wrote:
>
>> Marc Glisse wrote:
>>>
>>> On Mon, 4 Nov 2013, Richard Biener wrote:
>>>
Well, host_integer_p (, 0) looks correct to me. But ...
>>>
>>>
>>> Ok, I'll put it back.
>
>
> Er, actually host_int
On Mon, 4 Nov 2013, Richard Biener wrote:
Marc Glisse wrote:
On Mon, 4 Nov 2013, Richard Biener wrote:
Well, host_integer_p (, 0) looks correct to me. But ...
Ok, I'll put it back.
Er, actually host_integerp(, 0) can't work, because arithmetic on pointers
is done with unsigned integers
Marc Glisse wrote:
>On Mon, 4 Nov 2013, Richard Biener wrote:
>
>> Well, host_integer_p (, 0) looks correct to me. But ...
>
>Ok, I'll put it back.
>
>>> Index: gcc/tree-ssa-alias.h
>>> ===
>>> --- gcc/tree-ssa-alias.h(revisi
On Mon, 4 Nov 2013, Richard Biener wrote:
Well, host_integer_p (, 0) looks correct to me. But ...
Ok, I'll put it back.
Index: gcc/tree-ssa-alias.h
===
--- gcc/tree-ssa-alias.h(revision 204267)
+++ gcc/tree-ssa-alias.h
On Thu, Oct 31, 2013 at 6:11 PM, Marc Glisse wrote:
> On Wed, 30 Oct 2013, Richard Biener wrote:
>
>>> --- gcc/tree-ssa-alias.c(revision 204188)
>>> +++ gcc/tree-ssa-alias.c(working copy)
>>> @@ -567,20 +567,29 @@ void
>>> ao_ref_init_from_ptr_and_size (ao_ref *ref, tree ptr, tree
On Wed, 30 Oct 2013, Richard Biener wrote:
--- gcc/tree-ssa-alias.c(revision 204188)
+++ gcc/tree-ssa-alias.c(working copy)
@@ -567,20 +567,29 @@ void
ao_ref_init_from_ptr_and_size (ao_ref *ref, tree ptr, tree size)
{
HOST_WIDE_INT t1, t2;
ref->ref = NULL_TREE;
if (TRE
On Wed, Oct 30, 2013 at 1:43 PM, Marc Glisse wrote:
> On Wed, 30 Oct 2013, Richard Biener wrote:
>
>> On Wed, Oct 30, 2013 at 1:09 AM, Marc Glisse wrote:
>>>
>>> On Tue, 29 Oct 2013, Richard Biener wrote:
>>>
For the POINTER_PLUS_EXPR offset argument you should use
int_cst_value () to a
On Wed, 30 Oct 2013, Richard Biener wrote:
On Wed, Oct 30, 2013 at 1:09 AM, Marc Glisse wrote:
On Tue, 29 Oct 2013, Richard Biener wrote:
For the POINTER_PLUS_EXPR offset argument you should use
int_cst_value () to access it (it will unconditionally sign-extend)
and use host_integerp (..., 0
On Wed, Oct 30, 2013 at 1:09 AM, Marc Glisse wrote:
> On Tue, 29 Oct 2013, Richard Biener wrote:
>
>> For the POINTER_PLUS_EXPR offset argument you should use
>> int_cst_value () to access it (it will unconditionally sign-extend)
>> and use host_integerp (..., 0). That leaves the overflow possibi
On Tue, 29 Oct 2013, Richard Biener wrote:
For the POINTER_PLUS_EXPR offset argument you should use
int_cst_value () to access it (it will unconditionally sign-extend)
and use host_integerp (..., 0). That leaves the overflow possibility
in place (and you should multiply by BITS_PER_UNIT) which
On Sat, Oct 26, 2013 at 7:07 PM, Marc Glisse wrote:
> On Fri, 25 Oct 2013, Marc Glisse wrote:
>
>> On Fri, 25 Oct 2013, Richard Biener wrote:
>>
>>> you can followup with handling POINTER_PLUS_EXPR if you like.
>>
>>
>> Like this? (bootstrap+testsuite on x86_64-unknown-linux-gnu)
>>
>> 2013-10-26
On Fri, 25 Oct 2013, Marc Glisse wrote:
On Fri, 25 Oct 2013, Richard Biener wrote:
you can followup with handling POINTER_PLUS_EXPR if you like.
Like this? (bootstrap+testsuite on x86_64-unknown-linux-gnu)
2013-10-26 Marc Glisse
gcc/
* tree-ssa-alias.c (ao_ref_init_from_ptr_and_
On Fri, 25 Oct 2013, Richard Biener wrote:
you can followup with handling POINTER_PLUS_EXPR if you like.
Like this? (bootstrap+testsuite on x86_64-unknown-linux-gnu)
2013-10-26 Marc Glisse
gcc/
* tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Look for a
POINTER_PLUS_EXP
On 10/25/13 03:29, Marc Glisse wrote:
It doesn't get lost, but this is the missed optimization that malloc
results still alias with global pointers (here a function argument).
Taking into account the offset shouldn't change anything.
I think this is a different issue (but if you say improving
On Fri, 25 Oct 2013, Tobias Burnus wrote:
Marc Glisse wrote:
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it m
Marc Glisse wrote:
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it make sense? (I am a bit afraid of
losing some
On Fri, 25 Oct 2013, Richard Biener wrote:
Ah, so you are looking at call_may_clobber_ref_p_1 and its pointer handling
when special-casing builtins?
Yes.
Note that fields can only be disambiguated
if the size of the access is known
TBAA could also help sometimes.
(not sure what fancy att
On Fri, Oct 25, 2013 at 11:29 AM, Marc Glisse wrote:
> On Fri, 25 Oct 2013, Richard Biener wrote:
>
>> On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
>> wrote:
>>>
>>> On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse
>>> wrote:
On Thu, 24 Oct 2013, Jeff Law wrote:
> On 10/24/13
On Fri, 25 Oct 2013, Richard Biener wrote:
On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
wrote:
On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse wrote:
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find a
On Fri, Oct 25, 2013 at 10:59 AM, Richard Biener
wrote:
> On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse wrote:
>> On Thu, 24 Oct 2013, Jeff Law wrote:
>>
>>> On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
informat
On Fri, Oct 25, 2013 at 8:11 AM, Marc Glisse wrote:
> On Thu, 24 Oct 2013, Jeff Law wrote:
>
>> On 10/24/13 23:23, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> I noticed that in some cases we were failing to find aliasing
>>> information because we were only looking at an SSA_NAME variable,
>>> missi
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstra
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it make sense? (I am
Hello,
I noticed that in some cases we were failing to find aliasing information
because we were only looking at an SSA_NAME variable, missing the fact
that it was really an ADDR_EXPR. The attached patch passes
bootstrap+testsuite, does it make sense? (I am a bit afraid of losing some
type in
24 matches
Mail list logo
