#958 during ptcheck, Armv8 in Aarch64 mode has undefined symbols

Developer_(v3.11.x)
closed-fixed
None
5
2014-09-17
2014-08-23
No

using 3.11.29 with local mods for supporting ARMv8 in AArch64, including support for weakly ordered memory:
--- ATLAS.orig/include/atlas_pca.h 2014-08-07 19:55:08.000000000 +0000
+++ ATLAS/include/atlas_pca.h 2014-08-23 15:29:59.000000000 +0000
@@ -48,6 +48,11 @@
#define ATL_membarrier asm volatile ("dmb")
/ #define ATL_USEPCA 1 /
#endif
+#elif defined(ATL_ARCH_AARCH64)
+ #ifdef GNUC
+ #define ATL_membarrier asm volatile ("dmb 0")
+/ #define ATL_USEPCA 1 /
+ #endif
#elif defined(ATL_ARCH_IA64Itan) || defined(ATL_ARCH_IA64Itan2)
#ifdef GNUC
#define ATL_membarrier asm volatile ("mf")

/home/dnuechte/ATLAS/build.1/..//bin/qrtst.c:1228: undefined reference to ATL_C2Fsormqr' sqrtst_pt.o: In functionrqtest':
/home/dnuechte/ATLAS/build.1/..//bin/qrtst.c:1024: undefined reference to ATL_C2Fsormrq' sqrtst_pt.o: In functionlqtest':
/home/dnuechte/ATLAS/build.1/..//bin/qrtst.c:619: undefined reference to ATL_C2Fsormlq' sqrtst_pt.o: In functionqltest':
/home/dnuechte/ATLAS/build.1/..//bin/qrtst.c:826: undefined reference to ATL_C2Fsormql' /home/dnuechte/ATLAS/build.1/lib/libptlapack.a(ATL_stgelqf.o): In functionATL_stgelqf':
/home/dnuechte/ATLAS/build.1/..//src/lapack/ATL_gelqf.c:154: undefined reference to `clapack_ilaenv'

Discussion

  • Dave Nuechterlein

    make build appears to have completed normally.
    make check passes
    make time has reasonable results:
    Clock rate=2400Mhz

                   single precision        double precision
                *********************    ********************
                   real      complex       real      complex
    Benchmark   %   Clock   %   Clock   %   Clock   %   Clock
    =========   =========   =========   =========   =========
      kSelMM       155.9      159.7      143.5      147.3 
      kGenMM       155.9      159.7      143.5      147.3 
      kMM_NT        69.3       87.4       69.2       63.1 
      kMM_TN        83.4       99.5       95.7      103.5 
      BIG_MM       155.0      156.1      142.9      144.6 
       kMV_N        86.3      109.7       50.1       85.2 
       kMV_T        70.4      113.4       50.9       88.8 
       kGER        81.8       90.5       43.5       75.5
    
     
  • Dave Nuechterlein

    this build also has the modified tune/blas/gemm/tfc.c from support request 955 installed.

     
  • Dave Nuechterlein

    BTW, I am not convinced my dmb call is correct in atlas_pca.h is correct, but that certainly would not change the symbols created.

    In the aarch64 customization for AARCH64, libatomic_ops-7.4.2/src/atomic_ops/sysdeps/gcc/aarch64.h, the dmb they use is:
    asm volatile("dmb st" : : : "memory");

    There are two different barriers, dmb and dsb. The dsb is a bigger hammer, and enforces full synchronization, while the dmb is only a memory barrier. The argument to the dmb controls the scope of the call (inner/outer/all), and the type (load/store/both). A dmb 0, should do all/both. This may be overkill.

     
    • R. Clint Whaley

      R. Clint Whaley - 2014-08-23

      Yeah, I don't believe the ATL_membarrier is used anywhere in ATLAS anyway, so I don't think it needs to be defined at all. The idea was to be able to issue the barrier, and maybe seeing if we still have some of the performance advantage of skipping the OS even on weakly ordered caches.

      I wound up skipping doing that, since PowerPC requires some black magic to use (the IBM docs essentially say "here's how it ought to work, but it doesn't, and we aren't going to tell you what actually does"). The idea might be live still on ARM, but I'm not currently using.

       
  • R. Clint Whaley

    R. Clint Whaley - 2014-08-23

    Looks like something went wrong during the install, and it didn't build lapack for some reason. I think you'll have to post the error log for me to see where things died for you.

     
  • R. Clint Whaley

    R. Clint Whaley - 2014-08-23
    • assigned_to: R. Clint Whaley
     
  • Dave Nuechterlein

    I have added armv8 specific functions for managing the thread counters. I no longer see this problem.

    It would be fine by me to close this since I cannot reproduce it any more.

     
  • R. Clint Whaley

    R. Clint Whaley - 2014-09-17
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks