Hi,
> here's the updated version of the patch.
>
> The goal is to remove the 'i' iterator from the following example, by
> replacing 'i < n' with 'p < base + n'.
>
> void
> f (char *base, unsigned long int i, unsigned long int n)
> {
> char *p = base + i;
> do
> {
> *p = '\0';
>
On 08/25/2011 01:42 PM, Tom de Vries wrote:
> Hi Zdenek,
>
> here's the updated version of the patch.
>
> The goal is to remove the 'i' iterator from the following example, by
> replacing 'i < n' with 'p < base + n'.
>
> void
> f (char *base, unsigned long int i, unsigned long int n)
> {
> cha
Hi Zdenek,
here's the updated version of the patch.
The goal is to remove the 'i' iterator from the following example, by
replacing 'i < n' with 'p < base + n'.
void
f (char *base, unsigned long int i, unsigned long int n)
{
char *p = base + i;
do
{
*p = '\0';
p++;
i++;
On 03/15/2011 04:10 PM, Zdenek Dvorak wrote:
> Hi,
>
>> I'll try to explain what my intention with the code is, by looking at a
>> pre-ivopt level example.
>>
>> :
>> p_5 = p_3(D) + i_4(D);
>>
>> :
>> # p_1 = PHI
>> # i_2 = PHI
>> *p_1 = 0;
>> p_6 = p_1 + 1;
>> i_7 = i_2 + 1;
>> if
Hi,
> I'll try to explain what my intention with the code is, by looking at a
> pre-ivopt level example.
>
> :
> p_5 = p_3(D) + i_4(D);
>
> :
> # p_1 = PHI
> # i_2 = PHI
> *p_1 = 0;
> p_6 = p_1 + 1;
> i_7 = i_2 + 1;
> if (i_7 < n_8(D))
> goto ;
> else
> goto ;
>
> :
>
Hi Zdenek,
I rewrote the patch to remove the use of use_uses_inced_iv.
On 03/14/2011 03:03 PM, Zdenek Dvorak wrote:
> Hi,
>
>>> (since the use_uses_inced_iv test is meaningless).
>>
>> To me it seems use_uses_inced_iv has meaning:
>> - it models something: it states whether the comparison is usi
Hi,
> > (since the use_uses_inced_iv test is meaningless).
>
> To me it seems use_uses_inced_iv has meaning:
> - it models something: it states whether the comparison is using
> the iv increment result or the iv phi result.
but that has nothing to do with the value of the iv. For instance,
in
On 03/14/2011 01:55 PM, Zdenek Dvorak wrote:
> Hi,
>
it is trying to allow for
do
{
*p = '\0';
i++; /* use_uses_inced_iv == true */
p++; /* use_after_cand_inc == true */
if (!(i < n))
break;
}
while (1);
and
Hi,
> >> it is trying to allow for
> >>
> >> do
> >> {
> >> *p = '\0';
> >> i++; /* use_uses_inced_iv == true */
> >> p++; /* use_after_cand_inc == true */
> >> if (!(i < n))
> >> break;
> >> }
> >> while (1);
> >>
> >> and for
> >>
> >> do
> >> {
> >> *p = '\0';
>
On 03/14/2011 01:14 PM, Zdenek Dvorak wrote:
> Hi,
>
+ /* Determine if the exit test is formulated in terms of the phi or the
+ increment of the use iv. */
+ use_uses_inced_iv
+= gimple_code (SSA_NAME_DEF_STMT (use->iv->ssa_name)) != GIMPLE_PHI;
+
+ /* Det
Hi,
> >> + /* Determine if the exit test is formulated in terms of the phi or the
> >> + increment of the use iv. */
> >> + use_uses_inced_iv
> >> += gimple_code (SSA_NAME_DEF_STMT (use->iv->ssa_name)) != GIMPLE_PHI;
> >> +
> >> + /* Determine if the exit test is before or after the in
On 03/14/2011 10:58 AM, Zdenek Dvorak wrote:
> Hi,
>
>> diff -u gcc/tree-ssa-loop-ivopts.c gcc/tree-ssa-loop-ivopts.c
>> --- gcc/tree-ssa-loop-ivopts.c (working copy)
>> +++ gcc/tree-ssa-loop-ivopts.c (working copy)
>> @@ -1194,6 +1300,7 @@ record_use (struct ivopts_data *data, tr
>>
Hi,
> diff -u gcc/tree-ssa-loop-ivopts.c gcc/tree-ssa-loop-ivopts.c
> --- gcc/tree-ssa-loop-ivopts.c(working copy)
> +++ gcc/tree-ssa-loop-ivopts.c(working copy)
> @@ -1194,6 +1300,7 @@ record_use (struct ivopts_data *data, tr
> gimple stmt, enum use_type use_type)
> {
>
On 03/04/2011 11:37 PM, Zdenek Dvorak wrote:
> Hi,
>
>>/* Whether the loop body includes any function calls. */
>>bool body_includes_call;
>> +
>> + /* Whether the loop body includes any function calls that possibly have
>> side
>> + effects. */
>> + bool body_includes_side_effect
Hi,
>/* Whether the loop body includes any function calls. */
>bool body_includes_call;
> +
> + /* Whether the loop body includes any function calls that possibly have
> side
> + effects. */
> + bool body_includes_side_effect_call;
> };
>
> /* An assignment of iv candidates to
Hi Zdenek,
On 03/04/2011 02:57 PM, Tom de Vries wrote:
> On 03/04/2011 08:37 AM, Paolo Bonzini wrote:
>> On 03/03/2011 03:28 PM, Tom de Vries wrote:
>>> reg-tested on x86_64. Better?
>>
>> Yes, very much so
>
> Great. Thanks for the review.
>
>> (talking about patch 6.5; the other one is an
>>
On 03/04/2011 02:57 PM, Tom de Vries wrote:
The MAX_EXPR however
expands into control flow, and is not hoisted out of the outer loop,
while the rest of the bound calculation is.
That looks like a pass-ordering problem too (both on the tree level, for
ivopts versus invariant motion, and on the
On 03/04/2011 08:37 AM, Paolo Bonzini wrote:
> On 03/03/2011 03:28 PM, Tom de Vries wrote:
>> reg-tested on x86_64. Better?
>
> Yes, very much so
Great. Thanks for the review.
> (talking about patch 6.5; the other one is an
> optimization but not essential based on the new comments).
>
> Just
On 03/03/2011 03:28 PM, Tom de Vries wrote:
reg-tested on x86_64. Better?
Yes, very much so (talking about patch 6.5; the other one is an
optimization but not essential based on the new comments).
Just one question: what happens if the COND_EXPR is indeed turned into a
MAX_EXPR? Is it a mi
Hi Paolo,
On 03/03/2011 09:44 AM, Paolo Bonzini wrote:
> On 03/02/2011 11:01 PM, Tom de Vries wrote:
>> + if (TREE_CODE (nit) == COND_EXPR)
>> +{
>> + if (!loop_only_exit_p (loop, exit))
>> +return false;
>> +
>> + return iv_elimination_compare_lt (use, cand, bound, nit, com
20 matches
Mail list logo
