Code dependencies

I have several instances in my software code that states that the loop was not vectorized or parallelized because of a dependency and it leaves it at that. It does say what kind of dependency nor does it give any other info on it.

First, where can I read up on the type of dependencies? Second I know that some auto-vectorizing compilers can rewrite the c code removing the dependency and still maintain the integrity of the code and its logic. Can pgcc 13.1 Workstation do that?

Is there any other dependency removing software available?

Also, where can I read up on code dependencies in general?

Thanks in advance.

THX 1138.

First, where can I read up on the type of dependencies?

Here’s a couple articles if found by doing a web search. There probably more out there but I’ll leave that exercise to you.

Second I know that some auto-vectorizing compilers can rewrite the c code removing the dependency and still maintain the integrity of the code and its logic.

No compiler can simply remove a dependency and maintain the integrity of the code and it’s logic. It certainly can work around some dependencies or try to disprove them, but remove them, no.

You could add a compiler flag , or use the C99 restrict attribute, asserting to the compiler that the pointers don’t overlap and it’s ok to go ignore alias dependency. Also, the compiler could put run time checks to see if pointers overlap, if they don’t then enter the vector code, if they do, execute the loop sequentially.

Other times the compiler may be able to split a loop into multiple loops where one loop is vectorizable while the other is not. The dependency is still there, it’s just be moved to it’s own loop.

Also, the compiler can use partial vectorization where sub-sections of the loop are vectorized. Though this mostly only works when there is a control dependency, such as a branch or a call.

Can pgcc 13.1 Workstation do that?

Most of our optimizations are on with -Mvect, but there’s additional flags such as -Msafeptr, -Mvect=partial, -Mvect=assoc, -Mvect=gather

Is there any other dependency removing software available?

Sorry, I don’t know. My guess is that there are many that can detect dependencies, but remove them? doubtful. This would be changing your algorithm, which only the programmer can do.

Also, where can I read up on code dependencies in general?

How in-depth do you want to go? http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860/ref=pd_bxgy_b_text_y

Though, a better spot may be to look at some of the OpenMP tutorials Home - OpenMP, they usually have a section of code dependencies.

  • Mat

In a paper that is very old (20 years) titled “Vectorizing C Compilers: How Good Are They?” by Lauren L. Smith, several c compilers mostly for the Cray are evaluated on a test suite of c for loops. Each one is evaluated on the same for loops to see how many each can autovectorize. They all succeed to various degrees.

I guess the point that I am trying to make is that not all compilers that can autovectorize produce the same results. Each one working on the same c code produces different results. That to me means that they handle things like dependencies in a different way. Some may not handle the dependencies at all and just refuse to auto-paraellelize the or auto-vectorize the loop.

The author refers to a compilers dependency analyzer of an auto-vectorizing compiler and how it works. I am wondering how the pgcc 13.1 Workstation c compiler would compare in this group if it could be placed in the group.

All of the papers that i have read mention that hand vectorization is laborious and error prone. No Kidding!!!

So the way to go is to use an auto-vectorizing compiler to minimize the these two drawbacks outlined above. But, how does the Pgroup Workstation compiler compare to these very old compilers?

Any help appreciated. Thanks in advance.

Newport_j

Hi Newport_j,

I tried to find the C version of this code so I could give you a definitive answer, but unfortunately could not find them. The original Fortran versions from which these were based, are still on Netlib (http://www.netlib.org/benchmark/vectors) if you’re interested.

Since Michael Wolfe is cited in the article, I walked down to his office to see if he knew how well we’d do. While he doesn’t remember the exact 100 tests the paper used, he thought we’d be able to vectorize most of them (provided -Msafeptr was used). The only problems we may have are with the while loop from figure 14 due to the fact that “lim” is a pointer. If lim was a constant, then the while loop could be turned into a for loop and then vectorized. Also, we don’t always do a good job when conditionals are present in the loop.

  • Mat