Hi,
Just one question. You describe the pragma in the doco patch as:
+This pragma tells the compiler that the immediately following @code{for}
+loop can be executed in any loop index order without affecting the result.
+The pragma aids optimization and in particular vectorization as the
+compiler can then assume a vectorization safelen of infinity.
I'm not a specialist, but I was always told that the 'original'
meaning of ivdep (which I believe was introduced by Cray), was that
the compiler could assume that there are only forward dependencies in
the loop, but not that it can be executed in any order. The Intel docs
give this example:
void ignore_vec_dep(int *a, int k, int c, int m)
{
#pragma ivdep
for (int i = 0; i < m; i++)
a[i] = a[i + k] * c;
}
Given your description, this loop wouldn't be a candidate for ivdep,
as reversing the loop index order changes the semantics. I believe
that the way you interpret it (ie. setting vectorization safe length
to INT_MAX) is correct with respect to this other definition, though.
Is there any normative definition for such language extensions ?
Oh, and are there any plans to maintain this information in some way
till the back-end? Software pipelining could be another huge winner
for that kind of dependency analysis simplification.
Thanks,
Fred
On 10 October 2013 10:45, Tobias Burnus <bur...@net-b.de> wrote:
> Richard: Could you review the Gimple part? Thanks!
> Joseph: Could you have a look at the C part? Thanks!
>
> Jakub Jelinek wrote:
>>>
>>> + if (loop->latch)
>>> + FOR_EACH_EDGE (e, ei, loop->latch->succs)
>>> + {
>>> + if (e->dest->flags & BB_RTL)
>>> + break;
>>
>> I'd prefer Richard to review this (and probably Joseph the C FE part).
>> You can't really have loop->latch in GIMPLE and the successors
>> in RTL, so perhaps you can check that in the if (loop->latch) check
>> already.
>> GIMPLE_COND must be the last in the bb, can't be followed by debug stmts,
>> so you can safely use just gsi_last_bb (e->dest) instead.
>
>
> I have done the two modifications you suggested, fixed the formatting
> glitches. And completed it by another all-language bootstrap and regtesting.
> (Including also the separately posted Fortran [1] and the C++ [2] patches.)
> OK for the trunk?
>
> [1] http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00517.html
> [2] http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00656.html
>
>>> +#define SET_ANNOTATE_EXPR_ID(NODE, ID) \
>>> + (ANNOTATE_EXPR_CHECK(NODE)->base.u.version = ID)
>>
>> Likewise. Shouldn't it be = (ID) ?
>
>
> Probably less relevant for assignments, but for safety, it cannot harm.
>
> Tobias
