On Wed, Apr 11, 2012 at 11:25 AM, Bin.Cheng <amker.ch...@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 5:09 PM, Richard Guenther
> <richard.guent...@gmail.com> wrote:
>> On Wed, Apr 11, 2012 at 10:05 AM, Bin.Cheng <amker.ch...@gmail.com> wrote:
>>> On Wed, Apr 11, 2012 at 11:28 AM, Bin.Cheng <amker.ch...@gmail.com> wrote:
>
>>>
>>> Turns out if-conversion checks whether gimple statement traps or not.
>>> For the statement "d0_6 = d[D.5150_5];", it assumes rhs might trap,
>>> because it sees the index not INTEGER_CST.
>>
>> Yes. After sinking the load is no longer executed unconditionally but
>> if-conversion would make it so. This is information loss caused by
>> sinking.
>>
>>> Two questions:
>>> 1, The check can be enhanced in gimple_could_trap_p_1 for ARRAY_REF.
>>
>> No, the index may be out-of-bounds.
>
> Apart from this topic. Actually I mean we can do more bound check
> rather than assume
> out-of-bounds if the index is not CST.
> For this example, the source code is like:
>
> #define N 32
> int a[N], b[N];
> int d[N], e[N];
> int k[N];
>
> __attribute__((noinline, noclone)) void
> f4 (void)
> {
> int i;
> for (i = 0; i < N/2; ++i)
> {
> int d0 = d[2*i], e0 = e[2*i];
> int d1 = d[2*i+1], e1 = e[2*i+1];
> k[2*i] = a[2*i] >= b[2*i] ? d0 : e0;
> k[2*i+1] = a[2*i+1] >= b[2*i+1] ? d1 : e1;
> }
> }
>
> The load "d[2*i+1]" is never out-of-bound, right?
Right. value-range analysis could set TREE_NO_TRAP on the memory
reference.
>>
>>> 2, Should I check this before sinking load from memory? If yes, then why
>>> sink of
>>> store does not do such check?
>>
>> Sinking is never a problem - the code will only be executed less times. The
>> issue with if-conversion is that it speculates the loads / stores, so they
>> may
>> not trap if they were originally not executed.
>>
>> So this is a pass ordering issue - sinking and if-conversion have different
>> conflicting goals. Btw, you also make RTL if-conversion harder. I suppose
> Yes, I have already found a case resulting in bad basic block ordering
> at RTL level,
> though not sure it RTL if-conversion related.
>
>> you should try to avoid messing up if-conversion possibilities so early,
>> thus, not sink in these cases. The same issue is present
>> for non-loads that are possibly trapping. So I'm not even sure we can easily
>> detect these cases - apart from never sinking possibly trapping stmts.
>>
>> At least you could say that the side-effect of trapping has to be preserved
>> (note that we do not generally do that, which you might consider a bug).
>
> Understood. I have already tested to not sink possibly trapping stmt, but not
> sure whether this is still wanted in GCC.
In general the sinking is wanted. For non-trapping stmts it would be
obvious I think.
Richard.
> Thanks.
>
>
> --
> Best Regards.
