On 01/24/2017 03:15 AM, Richard Biener wrote:
The more I look at our SCCVN implementation, the more I want to explore
trying to re-use that infrastructure to simplify DOM.
Certainly having a single way to hash/record stmts/expressions on GIMPLE would
be nice. Not sure if the SCCVN one is perf
On Mon, Jan 23, 2017 at 5:07 PM, Jeff Law wrote:
> On 01/23/2017 02:50 AM, Richard Biener wrote:
So ideally DOM and EVRP would merge and CCP, copyprop and VRP
would merge. It's probably not possible (or wise) to merge their
lattices
(maybe to some extent)
>>>
>>>
>>>
On Mon, Jan 23, 2017 at 4:55 PM, Martin Sebor wrote:
>>> Yes, I see that. But when I change size_t to unsigned int (in LP64)
>>> like so:
>>>
>>> void g (int *p, int *q)
>>> {
>>> unsigned n = (unsigned)(p - q);
>>>
>>> if (n < 10)
>>> f (__builtin_alloca (n));
>>> }
>>>
>>> -
On 01/19/2017 05:17 AM, Aldy Hernandez wrote:
In the attached testcase, we have a clearly bounded case of alloca which
is being incorrectly reported:
void g (int *p, int *q)
{
size_t n = (size_t)(p - q);
if (n < 10)
f (__builtin_alloca (n));
}
The problem is that VRP gives us an ant
On 01/19/2017 05:17 AM, Aldy Hernandez wrote:
In the attached testcase, we have a clearly bounded case of alloca which
is being incorrectly reported:
void g (int *p, int *q)
{
size_t n = (size_t)(p - q);
if (n < 10)
f (__builtin_alloca (n));
}
The problem is that VRP gives us an ant
On 01/23/2017 02:50 AM, Richard Biener wrote:
So ideally DOM and EVRP would merge and CCP, copyprop and VRP
would merge. It's probably not possible (or wise) to merge their lattices
(maybe to some extent)
DOM's equivalency tables could be easily superceded by other
implementations. It's just
Yes, I see that. But when I change size_t to unsigned int (in LP64)
like so:
void g (int *p, int *q)
{
unsigned n = (unsigned)(p - q);
if (n < 10)
f (__builtin_alloca (n));
}
-Walloca-larger-than=100 still complains:
warning: argument to ‘alloca’ may be too large
note:
On Fri, Jan 20, 2017 at 8:48 PM, Jeff Law wrote:
> On 01/20/2017 01:17 AM, Richard Biener wrote:
>>
>> On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote:
>>>
>>> On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez
wrote:
>
>
On Fri, Jan 20, 2017 at 5:37 PM, Martin Sebor wrote:
> On 01/20/2017 01:17 AM, Richard Biener wrote:
>>
>> On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote:
>>>
>>> On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez
wrote:
>
>
On 01/20/2017 01:17 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote:
On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
In the attached testcase, we have a clearly bounded case of alloca which
is
being incorrec
On Fri, Jan 20, 2017 at 12:35:32PM -0700, Jeff Law wrote:
> > This may be a naive question but why is it not possible to create
> > such an SSA name?
> Time and space complexity. To get the range information in this case we
> have to create new SSA_NAMEs and PHI nodes to merge them at BB3.
Not ju
On 01/20/2017 09:37 AM, Martin Sebor wrote:
On 01/20/2017 01:17 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote:
On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez
wrote:
In the attached testcase, we have a clearly b
On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
In the attached testcase, we have a clearly bounded case of alloca which is
being incorrectly reported:
void g (int *p, int *q)
{
size_t n = (size_t)(p - q);
if (n < 10)
f (__builti
On 01/20/2017 01:17 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote:
On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
In the attached testcase, we have a clearly bounded case of alloca which
is
being incorrec
On Fri, Jan 20, 2017 at 11:52 AM, Aldy Hernandez wrote:
> On 01/20/2017 03:17 AM, Richard Biener wrote:
>>
>> On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote:
>>>
>>> On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez
wrote:
On 01/20/2017 03:17 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote:
On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
In the attached testcase, we have a clearly bounded case of alloca which
is
being incorrec
On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote:
> On 01/19/2017 05:45 AM, Richard Biener wrote:
>>
>> On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
>>>
>>> In the attached testcase, we have a clearly bounded case of alloca which
>>> is
>>> being incorrectly reported:
>>>
>>> void g
On 01/19/2017 05:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
In the attached testcase, we have a clearly bounded case of alloca which is
being incorrectly reported:
void g (int *p, int *q)
{
size_t n = (size_t)(p - q);
if (n < 10)
f (__builti
On Thu, Jan 19, 2017 at 2:02 PM, Aldy Hernandez wrote:
> On 01/19/2017 07:45 AM, Richard Biener wrote:
>>
>> On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
>>>
>>> In the attached testcase, we have a clearly bounded case of alloca which
>>> is
>>> being incorrectly reported:
>>>
>>> void
On 01/19/2017 07:45 AM, Richard Biener wrote:
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
In the attached testcase, we have a clearly bounded case of alloca which is
being incorrectly reported:
void g (int *p, int *q)
{
size_t n = (size_t)(p - q);
if (n < 10)
f (__builti
On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote:
> In the attached testcase, we have a clearly bounded case of alloca which is
> being incorrectly reported:
>
> void g (int *p, int *q)
> {
>size_t n = (size_t)(p - q);
>
>if (n < 10)
> f (__builtin_alloca (n));
> }
>
> The proble
In the attached testcase, we have a clearly bounded case of alloca which
is being incorrectly reported:
void g (int *p, int *q)
{
size_t n = (size_t)(p - q);
if (n < 10)
f (__builtin_alloca (n));
}
The problem is that VRP gives us an anti-range for `n' which may be out
of range:
22 matches
Mail list logo
