[PATCH] D96104: [test-suite] SPEC2017 CPU Fotonik3d floating point tests.

[Michael Kruse via Phabricator via llvm-commits]

Meinersbur added inline comments.


================
Comment at: External/SPEC/CFP2017rate/549.fotonik3d_r/CMakeLists.txt:63
+            "${TEST_SUITE_SPEC2017_ROOT}/bin/specxz"
+    COMMAND "${TEST_SUITE_SPEC2017_ROOT}/bin/specxz"
+            -dc "${INPUT_${_run_type}_DIR}/OBJ.dat.xz"
----------------
naromero77 wrote:
> Meinersbur wrote:
> > Files in this dir requires to run the install script, where I up to now just extracted the archive. (`specxz` is in `\tools\bin\$platform`). In addition, the platform on which cmake runs, llvm-lit is invoked, and the tests executables are running (`TEST_SUITE_REMOTE_HOST`) might not be the same. For which of these architecture is `specxz` supposed to be?
> > 
> > Is there any possibility to not require installation?
> I assume that SPEC CPU 2017 is installed by the user. The `object.pm` for fotonik3d includes a `sub generate_inputs` section which calls `specxz`. So, if you just run the SPEC CPU 2017 installer it will not create the needed `OBJ.dat`, it is created on the fly.
> 
> The `specxz` that is pointed to in `object.pm`is
> `'command'   => ::jp($ENV{SPEC}, "bin", "specxz"),`
> 
> Your point is that that I might be using the wrong `specxz`? This is called while the tests are being built (after cmake, during make, but before the call to llvm-lit), which is normally the host? Is `${TEST_SUITE_SPEC2017_ROOT}/bin/specxz` not for the host?
> 
>From how I understand from `install.sh`, `${TEST_SUITE_SPEC2017_ROOT}/bin/specxz` contains the copy of the file that corresponds to the architecture as returned by `uname`.

I see that this is the behavior of SPEC itself, but I liked the convenience of just dumping the spec2017 files into one directory, e.g. an NFS location to be used from multiple platforms.

Possibilities to avoid the installation:
1. Use `xz` as installed on the host.
2. Autodetect the architecture in the CMakeLists.txt
3. Try out all specxz executables, stop with the one that worked
4. Let cmake compile 557.xz_r (`spec_xz.c`) and use that executable.

I am not sure whether this would be worth the effort, but it would be nice.


Repository:
  rT test-suite

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96104/new/

https://reviews.llvm.org/D96104