Re: IVOPT improvement patch

[Xinliang David Li <davidxl at google dot com>]

On Fri, May 28, 2010 at 2:14 AM, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> Hi,
>
>> patch-4:
>>
>> A simple local optimization that reorders iv update statement with
>> preceding target_mem_ref so that instruction combining can happen in
>> later phases.
>
>> +/* Performs a peephole optimization to reorder the iv update statement with
>> + ? a mem ref to enable instruction combining in later phases. The mem ref uses
>> + ? the iv value before the update, so the reordering transformation requires
>> + ? adjustment of the offset. CAND is the selected IV_CAND.
>> +
>> + ? Example:
>> +
>> + ? t = MEM_REF (base, iv1, 8, 16); ?// base, index, stride, offset
>> + ? iv2 = iv1 + 1;
>> +
>> + ? if (t < val) ? ? ?(1)
>> + ? ? goto L;
>> + ? goto Head;
>> +
>> +
>> + ? directly propagating t over to (1) will introduce overlapping live range
>> + ? thus increase register pressure. This peephole transform it into:
>> +
>> +
>> + ? iv2 = iv1 + 1;
>> + ? t = MEM_REF (base, iv2, 8, 8);
>> + ? if (t < val)
>> + ? ? goto L;
>> + ? goto Head;
>> +*/
>
> looks reasonable. ?Just two notes:
> 1) you should check whether the new value of the offset is allowed for the
> ? current architecture.

What query should be used? It is not checked in maybe_fold_tmr call
nor tmr creation in ivopts.

> 2) rather than rewriting the resulting code, it might be easier to change the
> ? position of the candidate (to IP_BEFORE_USE for the use in the memory
> ? reference) before create_new_ivs is run.
>

There is ordering issue -- the target tmr operation for this
optimization is created after address use rewrite. It might be doable
as your suggested, but may be more intrusive.

Thanks,

David

> Zdenek
>