Assessment of the difficulty in porting CPU architecture for libmesh

[wangyuliu]

Hello everyone! I am working on implementing a tool to assess the complexity of CPU architecture porting. It primarily focuses on RISC-V architecture porting. In fact, the tool may have an average estimate of various architecture porting efforts.My focus is on the overall workload and difficulty of transplantation in the past and future,even if a project has already been ported.As part of my dataset, I have collected the libmesh project. I would like to gather community opinions to support my assessment. I appreciate your help and response! Based on scanning tools, the porting complexity is determined to be high, with a significant amount of code related to the CPU architecture in the project. Is this assessment accurate?Do you often any opinions on personnel allocation and consumption time？ I look forward to your help and response.

[dschwen]

Could you give some examples of libmesh code detected as being related to the CPU architecture?

[wangyuliu]

We have detected nearly two thousand lines of assembly code：
asm volatile
(
BOOST_ATOMIC_DETAIL_ARM_ASM_START(%[tmp])
"1:\n"
"ldrex %[original], %[storage]\n" "add %[result], %[original], %[value]\n" "uxth %[result], %[result]\n" "strex %[tmp], %[result], %[storage]\n" "teq %[tmp], #0\n" "bne 1b\n" BOOST_ATOMIC_DETAIL_ARM_ASM_END(%[tmp])
: [original] "=&r" (original), [result] "=&r" (result), [tmp] "=&l" (tmp), [storage] "+Q" (storage) : [value] "r" (v) : BOOST_ATOMIC_DETAIL_ASM_CLOBBER_CC
)
There are also some architectural macros and many Intrinsic functions：
#if defined(_M_AMD64) || defined(_M_IA64)
#define BOOST_ATOMIC_DETAIL_SIZEOF_POINTER 8
#else
#define BOOST_ATOMIC_DETAIL_SIZEOF_POINTER 4
#endif#ifndef __x86_64
if(keep_powi) { sim.Eat(1, cInt); break; }
#endif#if defined _WIN64
#if !defined _M_IA64 && !defined _M_AMD64
#endif
#endif#ifndef EIGEN_GENERAL_BLOCK_PANEL_H
#define EIGEN_GENERAL_BLOCK_PANEL_H

[jwpeterson]

This assembly code is in boost and possibly Eigen, these are libraries found in the "contrib" directory, and are not part of libmesh itself...

[jwpeterson]

My main comment is that we always strive to write platform-independent, standards-conforming code as much as possible. Therefore if a new architecture has a working C++17-compliant compiler, it generally does not require much additional work to build libmesh on that architecture.