[PATCH] D99640: [test-suite] SPEC2017 CPU pop2 floating point test.
Michael Kruse via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 31 12:08:32 PDT 2021
Meinersbur added inline comments.
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:12
+macro(pop2_prepare_rundir)
+ # Similar to the spec2017_prepare_rundir with an input file fix.
+ # input file for pop2 is hard-coded to drv_in, but actual filename
----------------
Meinersbur wrote:
> How does the SPEC .pm driver handle this?
>
> Did you consider invoking `speccpu2017_prepare_rundir` and just fix the file name after that (Instead of copy-pasting its code)?
> ```
> spec2017_prepare_rundir()
> foreach (_runtype IN LISTS TEST_SUITE_RUN_TYPE)
> llvm_copy(${PROG} "${RUN_${_runtype}_DIR}/drv_in" "${INPUT_${_runtype}_DIR}/drv_in.in")
> endforeach ()
> ```
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:12-15
+ # Similar to the spec2017_prepare_rundir with an input file fix.
+ # input file for pop2 is hard-coded to drv_in, but actual filename
+ # in SPEC2017 benchmark input directory is drv_in.in. The SPEC perl
+ # run script renames the file as well.
----------------
How does the SPEC .pm driver handle this?
Did you consider invoking `speccpu2017_prepare_rundir` and just fix the file name after that (Instead of copy-pasting its code)?
```
spec2017_prepare_rundir()
foreach (_runtype IN LISTS TEST_SUITE_RUN_TYPE)
llvm_copy(${PROG} "${RUN_${_runtype}_DIR}/drv_in" "${INPUT_${_runtype}_DIR}/drv_in.in")
endforeach ()
```
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:35
+
+# Compiler definitions affect C and *.f90 files, but note *.F90 files.
+# Following flags get added automatically by SpecCPU2017.cmake and not
----------------
[typo] not~~e~~
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:37
+# Following flags get added automatically by SpecCPU2017.cmake and not
+# include below:
+# -DSPEC -DSPEC_CPU -DNDEBUG
----------------
The value of `SPEC_AUTO_BYTEORDER` depends on the host machine. Some other are added as well. Not sure it makes sense to list the generic SPEC definitions here.
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:66
+# end up with a ridiculously long line that some compilers, like
+# GCC, are unable to compile.
+speccpu2017_run_specpp(
----------------
Do I understand correctly, gfortran has problems to compile long lines? Is this a problem with the vanilla SPEC as well if installed in a deeply nested directory?
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:83-84
+ -DSPEC_CASE_FLAG
+ -DSPEC_AUTO_BYTEORDER=${SPEC_AUTO_BYTEORDER_VALUE}
+ -DSPEC_${SPEC_PTR_TYPE}
+ -DSPEC_SUPPRESS_OPENMP
----------------
It is kind-of intransparent where SPEC_AUTO_BYTEORDER_VALUE and SPEC_PTR_TYPE come from. Did you consider assemble a list preprocessor definitions shared between all CPU2017 benchmarks and make `speccpu2017_run_specpp` add them implicitly (Liek they are added implicitly for the source files themselves)? Similaryl, `-U__FILE__` and `-w` don't seem to be specific to pop2.
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:105
+# SPEC Test has both absolute and relative tolerance with same order
+speccpu2017_verify_output(IGNORE_WHITE_SPACE ABSOLUTE_TOLERANCE 0.03 RELATIVE_TOLERANCE 0.03)
+
----------------
If it works without `IGNORE_WHITESPACE`, is it even needed?
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:109
+# directory
+speccpu2017_add_executable(
+ netcdf/attr.c
----------------
Is listing the files needed (e.g. because some files must not linked into the executable) or could it also be done with a `file(GLOB_RECURSIVE ...)`?
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:437
+
+check_fortran_compiler_flag("-fallow-argument-mismatch" SUPPORTS_FALLOW_ARGUMENT_MISMATCH)
+if (SUPPORTS_FALLOW_ARGUMENT_MISMATCH)
----------------
Could this somehow be shared with 527.cam4_r, e.g. by moving both into `SpecCPU2017.cmake`?
================
Comment at: External/SPEC/CFP2017speed/628.pop2_s/CMakeLists.txt:458
+ "628.pop2_s not supported. No way to read big-endian binary IO on little-endian architecture.")
+ return ()
+ endif ()
----------------
`speccpu2017_verify_output` will have been called already at this point, only `pop2_prepare_rundir` is skipped when returning in this point, i.e. it will still try to run pop2 and fail because of files missing. Move this check to the beginning?
================
Comment at: External/SPEC/SpecCPU2017.cmake:363
+
+# Run specpp on all Fortran files, but do not do it recursively
+macro(speccpu2017_run_specpp)
----------------
Could explain here why running specpp is needed (instead of the Fortran-compiler's integrated preprocessor)?
================
Comment at: External/SPEC/SpecCPU2017.cmake:366-368
+ # We don't use GLOB_RECURSE below, because the stdout redirects
+ # don't include relative path of the source file. Hence, there could
+ # potentially be two files with the same name in different directories.
----------------
Could use `GLOB_RECURSIVE RELATIVE {SRC_DIR}` or `file(RELATIVE_PATH)` instead of get_filename_component to get a relative path. Might need `file(MAKE_DIRECTORY ` if specpp doesn't create directories itself.
This assumes that there even are files in subdirectories that need to be processed.
================
Comment at: External/SPEC/SpecCPU2017.cmake:374
+ OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${_filename}"
+ COMMAND "${_specpp_bin}" ${ARGN} "${_absfilename}" > "${CMAKE_CURRENT_BINARY_DIR}/${_filename}"
+ DEPENDS "${_absfilename}"
----------------
[Idea] Use of `target_sources` to add the file to the executable instead of needing to list it in `speccpu2017_add_executable`
Files that need to go trough specpp could also be specified as a "SPECPP_SOURCES" argument of `speccpu2017_add_executable` and share the preprocessor definitions.
Repository:
rT test-suite
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D99640/new/
https://reviews.llvm.org/D99640
More information about the llvm-commits
mailing list