Hi,
On Mon, 20 Jun 2011, Richard Guenther wrote:
> > of the specifications; rather, we should consider whether there is a
> > situation where a user could reasonably expect NULL + 0 to be valid.
> > In the example by Richard,
> >
> > int __attribute__((noinline)) foo (void *p, int i)
> > {
> >
On Mon, Jun 20, 2011 at 2:25 PM, Zdenek Dvorak wrote:
>> > I don't think we should move this kind of undefinedness from C to
>> > the GIMPLE semantics. What do other languages allow that
>> > we have to support (what did K&R C specify?).
>>
>> I don't think there is a formal specification of K&R
> > I don't think we should move this kind of undefinedness from C to
> > the GIMPLE semantics. What do other languages allow that
> > we have to support (what did K&R C specify?).
>
> I don't think there is a formal specification of K&R C, just the (somewhat
> informal) book. On topic of pointe
> I don't think we should move this kind of undefinedness from C to
> the GIMPLE semantics. What do other languages allow that
> we have to support (what did K&R C specify?).
I don't think there is a formal specification of K&R C, just the (somewhat
informal) book. On topic of pointer arithmetic
2011/6/17 Jeff Law :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/17/11 08:12, Zdenek Dvorak wrote:
>
if we do, we definitely should not -- the only point of such a
construction is
to bypass the pointer arithmetics restrictions,
>>>
>>> Ok, we don't. Where does the C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/11 08:12, Zdenek Dvorak wrote:
>>> if we do, we definitely should not -- the only point of such a construction
>>> is
>>> to bypass the pointer arithmetics restrictions,
>>
>> Ok, we don't. Where does the C standard say that NULL + 0 is und
Hi,
> >> >> > Index: tree-vrp.c
> >> >> > ===
> >> >> > --- tree-vrp.c (revision 173703)
> >> >> > +++ tree-vrp.c (working copy)
> >> >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra
> >> >> > {
> >> >> >
2011/6/17 Zdenek Dvorak :
> Hi,
>
>> >> > Index: tree-vrp.c
>> >> > ===
>> >> > --- tree-vrp.c (revision 173703)
>> >> > +++ tree-vrp.c (working copy)
>> >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra
>> >> >
Hi,
> >> > Index: tree-vrp.c
> >> > ===
> >> > --- tree-vrp.c (revision 173703)
> >> > +++ tree-vrp.c (working copy)
> >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra
> >> > {
> >> > /* For point
2011/6/17 Zdenek Dvorak :
>> >> Interesting. I'd never thought about the generation/use angle to prove
>> >> a pointer was non-null. ISTM we could use that same logic to infer that
>> >> more pointers are non-null in extract_range_from_binary_expr.
>> >>
>> >> Interested in tackling that improvem
> >> Interesting. I'd never thought about the generation/use angle to prove
> >> a pointer was non-null. ISTM we could use that same logic to infer that
> >> more pointers are non-null in extract_range_from_binary_expr.
> >>
> >> Interested in tackling that improvement, obviously as an independen
On Fri, Jun 17, 2011 at 12:40 PM, Tom de Vries wrote:
> On 06/17/2011 12:01 AM, Jeff Law wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 06/16/11 00:39, Tom de Vries wrote:
>>> Hi,
>>>
>>> Consider the following example.
>>>
>>> extern unsigned int foo (int*) __attribute__((pur
On 06/17/2011 12:01 AM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/16/11 00:39, Tom de Vries wrote:
>> Hi,
>>
>> Consider the following example.
>>
>> extern unsigned int foo (int*) __attribute__((pure));
>> unsigned int
>> tr (int array[], int n)
>> {
>> unsigne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/16/11 00:39, Tom de Vries wrote:
> Hi,
>
> Consider the following example.
>
> extern unsigned int foo (int*) __attribute__((pure));
> unsigned int
> tr (int array[], int n)
> {
> unsigned int i;
> unsigned int sum = 0;
> for (i = 0; i <
On 06/16/2011 05:42 PM, Zdenek Dvorak wrote:
diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
(working copy)
--- gcc/tree-ssa-loop-niter.c (working copy)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -2875,6 +2875,16 @@
low = lower_bound
> >> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
> >> (working copy)
> >> --- gcc/tree-ssa-loop-niter.c (working copy)
> >> +++ gcc/tree-ssa-loop-niter.c (working copy)
> >> @@ -2875,6 +2875,16 @@
> >> low = lower_bound_in_type (type, type);
> >> high = upper_b
On Thu, Jun 16, 2011 at 5:24 PM, Zdenek Dvorak wrote:
> Hi,
>
>> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
>> (working copy)
>> --- gcc/tree-ssa-loop-niter.c (working copy)
>> +++ gcc/tree-ssa-loop-niter.c (working copy)
>> @@ -2875,6 +2875,16 @@
>> low = lower
Hi,
> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c
> (working copy)
> --- gcc/tree-ssa-loop-niter.c (working copy)
> +++ gcc/tree-ssa-loop-niter.c (working copy)
> @@ -2875,6 +2875,16 @@
>low = lower_bound_in_type (type, type);
>high = upper_bound_in_type (ty
On 06/16/2011 09:24 AM, Zdenek Dvorak wrote:
> Hi,
>
>> Consider the following example.
>>
>> extern unsigned int foo (int*) __attribute__((pure));
>> unsigned int
>> tr (int array[], int n)
>> {
>> unsigned int i;
>> unsigned int sum = 0;
>> for (i = 0; i < n; i++)
>> sum += foo (&array
Hi,
> Consider the following example.
>
> extern unsigned int foo (int*) __attribute__((pure));
> unsigned int
> tr (int array[], int n)
> {
> unsigned int i;
> unsigned int sum = 0;
> for (i = 0; i < n; i++)
> sum += foo (&array[i]);
> return sum;
> }
>
> For 32-bit pointers, the an
On 06/16/2011 08:39 AM, Tom de Vries wrote:
> I will sent the adapted test cases in a separate email.
Update 2 test cases to be more strict, and more like the original example.
Thanks,
- Tom
2011-06-15 Tom de Vries
PR target/45098
* gcc.target/arm/ivopts-3.c: Update test.
Hi,
Consider the following example.
extern unsigned int foo (int*) __attribute__((pure));
unsigned int
tr (int array[], int n)
{
unsigned int i;
unsigned int sum = 0;
for (i = 0; i < n; i++)
sum += foo (&array[i]);
return sum;
}
For 32-bit pointers, the analysis in infer_loop_bounds_
Hi,
> > I think a better fix would be to make the nb_iterations_upper_bound
> > semantics
> > consistent with that of nb_iterations. Let me try to do it, hopefully this
> > should
> > be mostly mechanical,
> >
>
> This patch changes the semantics of nb_iterations_upper_bound and
> nb_iteratio
Hi Zdenek,
On 05/31/2011 10:04 AM, Zdenek Dvorak wrote:
> Hi,
>
>> As far as I can tell, what is current calculated in i_bound (and assigned to
>> nb_iterations_upper_bound), is the maximum amount of times any statement in
>> the
>> loop is executed, where any includes exit tests. Differently pu
Hi Tom,
Thanks for the reply, and sorry for responding so slowly.
Tom de Vries writes:
> On 05/25/2011 03:44 PM, Richard Sandiford wrote:
>> Sorry for being so late. I was just curious...
>>
>> Tom de Vries writes:
>>> The init cost of an iv will in general not be zero. It will be
>>> excepti
Hi,
> As far as I can tell, what is current calculated in i_bound (and assigned to
> nb_iterations_upper_bound), is the maximum amount of times any statement in
> the
> loop is executed, where any includes exit tests. Differently put, the maximum
> amount of times the loop header is executed.
hm
On 05/30/2011 02:38 PM, Zdenek Dvorak wrote:
> Hi,
>
>>> The header block of the loop is bb 4, the latch block is bb 3:
>>> ...
>>> (gdb) p loop.header.index
>>> $4 = 4
>>> (gdb) p loop.latch.index
>>> $5 = 3
>>> ...
>>>
>>> The number of times the latch edge is executed, is 10.
>>>
>>> But loop->
Hi,
> > The header block of the loop is bb 4, the latch block is bb 3:
> > ...
> > (gdb) p loop.header.index
> > $4 = 4
> > (gdb) p loop.latch.index
> > $5 = 3
> > ...
> >
> > The number of times the latch edge is executed, is 10.
> >
> > But loop->nb_iterations_upper_bound, or max_niter is 11:
Hi Zdenek,
On 05/21/2011 07:59 PM, Tom de Vries wrote:
> On 05/21/2011 02:24 PM, Zdenek Dvorak wrote:
>>> * tree-ssa-loop-ivopts.c (may_eliminate_iv): Fix
>>> estimated_loop_iterations comparison.
>>
>> I don't think this part is correct, though:
>>
>>> Index: gcc/tree-ssa-loop-ivopts.c
>>
Hi Richard,
On 05/25/2011 03:44 PM, Richard Sandiford wrote:
> Sorry for being so late. I was just curious...
>
> Tom de Vries writes:
>> The init cost of an iv will in general not be zero. It will be
>> exceptional that the iv register happens to be initialized with the
>> proper value at no c
Sorry for being so late. I was just curious...
Tom de Vries writes:
> The init cost of an iv will in general not be zero. It will be
> exceptional that the iv register happens to be initialized with the
> proper value at no cost. In general, there will at the very least be a
> regcopy or a const
On Sat, May 21, 2011 at 5:24 AM, Zdenek Dvorak wrote:
> Hi,
>
>> > Would it be possible to add the handling of these cases
>> > to estimate_numbers_of_iterations, rather than doing it just for ivopts?
>>
>> Yes, I did that now.
>>
>> Thanks,
>> - Tom
>>
>> 2011-05-05 Tom de Vries
>>
>> PR
> I didn't manage to reproduce the breakage, but I think this patch will fix
> it.
You need a 32-bit host.
> The patch makes sure cst_and_fits_in_hwi is tested before using
> int_cst_value.
This should be sufficient indeed, thanks.
> 2011-05-22 Tom de Vries
>
> PR target/45098
>
On Sun, May 22, 2011 at 6:06 PM, Tom de Vries wrote:
> On 05/21/2011 09:40 AM, Eric Botcazou wrote:
>>> 2011-05-05 Tom de Vries
>>>
>>> PR target/45098
>>> * tree-ssa-loop-ivopts.c: Include expmed.h.
>>> (get_shiftadd_cost): New function.
>>> (force_expr_to_var_cost): Declar
On 05/21/2011 09:40 AM, Eric Botcazou wrote:
>> 2011-05-05 Tom de Vries
>>
>> PR target/45098
>> * tree-ssa-loop-ivopts.c: Include expmed.h.
>> (get_shiftadd_cost): New function.
>> (force_expr_to_var_cost): Declare forward. Use get_shiftadd_cost.
>
> This breaks the Ada co
On 05/21/2011 02:24 PM, Zdenek Dvorak wrote:
>> * tree-ssa-loop-ivopts.c (may_eliminate_iv): Fix
>> estimated_loop_iterations comparison.
>
> I don't think this part is correct, though:
>
>> Index: gcc/tree-ssa-loop-ivopts.c
>> ===
Hi,
> > Would it be possible to add the handling of these cases
> > to estimate_numbers_of_iterations, rather than doing it just for ivopts?
>
> Yes, I did that now.
>
> Thanks,
> - Tom
>
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-niter.c (infer_loop_bounds_
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c: Include expmed.h.
> (get_shiftadd_cost): New function.
> (force_expr_to_var_cost): Declare forward. Use get_shiftadd_cost.
This breaks the Ada compiler on x86:
/home/eric/build/gcc/native32/./gcc
Hi,
> On 05/18/2011 11:20 PM, Zdenek Dvorak wrote:
> >> + sa_cost = (TREE_CODE (expr) != MINUS_EXPR
> >> + ? shiftadd_cost[speed][mode][m]
> >> + : (mult == op1
> >> +? shiftsub1_cost[speed][mode][m]
> >> +: shiftsub0_cost[speed][mode][m]));
On 05/18/2011 11:11 PM, Zdenek Dvorak wrote:
> Hi,
>
>> This patch attemps to estimate the number of iterations of the loop based on
>> nonwrapping arithmetic in the loop body.
>>
>> 2011-05-05 Tom de Vries
>>
>> PR target/45098
>> * tree-ssa-loop-ivopts.c (struct ivopts_data): Add fi
Hi,
On 05/18/2011 11:20 PM, Zdenek Dvorak wrote:
>> + sa_cost = (TREE_CODE (expr) != MINUS_EXPR
>> + ? shiftadd_cost[speed][mode][m]
>> + : (mult == op1
>> +? shiftsub1_cost[speed][mode][m]
>> +: shiftsub0_cost[speed][mode][m]));
>> + res =
On 05/17/2011 09:14 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
Hi,
> + sa_cost = (TREE_CODE (expr) != MINUS_EXPR
> + ? shiftadd_cost[speed][mode][m]
> + : (mult == op1
> +? shiftsub1_cost[speed][mode][m]
> +: shiftsub0_cost[speed][mode][m]));
> + res = new_cost (sa_cost, 0);
> + res = add_costs (res,
Hi,
> Resubmitting with comment.
>
> This improves the estimation of cost of bound calculation:
> - It tries to estimate whether an ssa_name can be used in the loop
> at zero cost, or whether a regcopy is needed to keep the ssa_name
> alive during the loop, and counts the cost of the regcopy.
Hi,
> This patch attemps to estimate the number of iterations of the loop based on
> nonwrapping arithmetic in the loop body.
>
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (struct ivopts_data): Add fields
> max_iterations_p and max_iterations.
>
Hi,
> Resubmitting with comment.
>
> The init cost of an iv will in general not be zero. It will be
> exceptional that the iv register happens to be initialized with the
> proper value at no cost. In general, there will at the very least be a
> regcopy or a const set.
OK. Please add a comment e
Hi Zdenek,
On 05/18/2011 05:24 PM, Zdenek Dvorak wrote:
> Hi,
>
>> How about:
>> ...
>> @@ -2866,6 +2878,8 @@ computation_cost (tree expr, bool speed)
>>if (MEM_P (rslt))
>> cost += address_cost (XEXP (rslt, 0), TYPE_MODE (type),
>>TYPE_ADDR_SPACE (type), speed);
On 05/17/2011 09:24 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:21 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:21 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:20 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:19 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:18 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
On 05/17/2011 09:17 AM, Tom de Vries wrote:
> On 05/17/2011 09:10 AM, Tom de Vries wrote:
>> Hi Zdenek,
>>
>> I have a patch set for for PR45098.
>>
>> 01_object-size-target.patch
>> 02_pr45098-rtx-cost-set.patch
>> 03_pr45098-computation-cost.patch
>> 04_pr45098-iv-init-cost.patch
>> 05_pr45098-bo
Hi Zdenek,
thanks for the review.
On 05/18/2011 09:26 AM, Zdenek Dvorak wrote:
>> 2011-05-05 Tom de Vries
>>
>> PR target/45098
>> * tree-ssa-loop-ivopts.c (computation_cost): Prevent cost of 0.
>
> this looks strange. Something like
>
> cost = seq_cost (seq, speed);
> if (MEM
Hi,
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (computation_cost): Prevent cost of 0.
this looks strange. Something like
cost = seq_cost (seq, speed);
if (MEM_P (rslt))
the current code;
else
cost += rtx_cost (rslt, SET, speed));
woul
Hi,
> 2011-05-05 Tom de Vries
>
> PR target/45098
> * tree-ssa-loop-ivopts.c (seq_cost): Fix call to rtx_cost.
OK,
Zdenek
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
Hi Zdenek,
I have a patch set for for PR45098.
01_object-size-target.patch
02_pr45098-rtx-cost-set.patch
03_pr45098-computation-cost.patch
04_pr45098-iv-init-cost.patch
05_pr45098-bound-cost.patch
06_pr45098-bound-cost.test.patch
07_pr45098-nowrap-limits-iterations.patch
08_pr45098-nowrap-limits-
68 matches
Mail list logo
