popcorn-compiler
popcorn-compiler copied to clipboard
ssrg-vt
Relocation Overflow Error
Problem
While trying to compile NPB-OMP, I encountered this error. The problem is that some NPB benchmarks uses large tables, which lead to this type of error. This error comes up in at least to benchs: MG, FT with CLASS C.
(EDIT: This problem happens also in the SERIAL version of NPB! Wondering why no one raised the red flag?)
Potential Solution
Rob suggested to use the -mcmodel=large option to overcome this problem. Trying it on the application alone led to a linking error. Which make sense, since we are linking binaries with different models. Trying to recompile all libraries with the large model led to another error signaled by CLang: "ELF TLS only supported in small memory model"! This error happens while compiling libopenpop (OpenMP library).
(EDIT: probably mcmodel=large may work on the serial version of NPB since TLS is not used)
Wondering how things work with GCC for native compilation? EDIT: they use shared libraries+ "-mcmodel=medium" (an explanation of why it work at: https://software.intel.com/en-us/articles/avoiding-relocation-errors-when-building-applications-with-large-global-or-static-data-on-intel64).
I don't have a fix, but this is a known (but not documented until now) issue with some of the class C benchmarks.
We've previously dealt with it by simply ignoring class C for the problematic benchmarks. Obviously not sustainable in the long-term, of course.
Could this be solved by changing the enormous amount of static data NPB is declaring (especially in Class C) to malloc?
Yes, very probably. But we would like to avoid modifying the applications(?)
I did it previously for IS, it was pretty easy. What is the reason behind not modifying the applications?
AFAIK: Until known, one of the selling point of popcorn was that it "Bridges the Programmability Gap in Heterogeneous-ISA Platforms". Meaning that unmodified applications can run on heterogeneous platform. If we start saying that <<we modified the applications to overcome this problem, although this problem has nothing to do with heterogeneity...>> It may delude our claim?
No, in my opinion it is fine. It's your research so your choice in the end, but one might argue that changing this giant amount of static memory to dynamically allocated one is actually making NPB closer to a real application ...
Update -- when digging into some TLS fixes I learned that LLVM uses R_AARCH64_TLSLE_ADD_TPREL_[HI12 | LO12] relocations for TLS addresses. These two relocations combine together to give a total addressable range from 0 - 2^24 (16 MB) from the TLS pointer. Because we're currently restricted to the initial-exec TLS model, there's not much we can do from the compiler side. So, if your application is using more than 16MB of TLS, it'll have to be changed to compile.
