This is an archive of the discontinued LLVM Phabricator instance.

detect FP contraction at test-time, disable certain subtests if detected
AbandonedPublic

Authored by Abe on Oct 14 2016, 4:31 PM.

Details

Summary

The program in the new file [when compiled with Clang] outputs "(1 1 1) (1 1) (1)" when no FP contraction is detected, and one or more of those 1s is replaced with a 0 when some FP contraction is detected.

Note: the new program is not guaranteed to always perfectly detect contraction with all compilers [only Clang and GCC were tested by Abe]. This is a best-effort approach that is as portable as Abe knows how to make it. When the detection program errs, it should err on the side of reporting a 1 when it should have reported a zero. Reporting a 0 when it should have reported a 1 should not be possible.

I [Abe] would appreciate help/suggestions on how to make the Makefile test harness run this program [prefereably only once per test run] and capture the result in a variable. Although I am quite proficient in GNU Make, I`m unsure how it is being [mis]used as a test harness for the LLVM "test-suite".

Added Oct. 17 2016, as per suggestion by Matthias: the program now returns an exit code of 0 only if no contraction was detected, 1 if any was.

Diff Detail

Event Timeline

Abe updated this revision to Diff 74750.Oct 14 2016, 4:31 PM
Abe retitled this revision from to detect FP contraction at test-time, disable certain subtests if detected.
Abe updated this object.
Abe added reviewers: sebpop, MatzeB, rengolin.
Abe updated this object.Oct 14 2016, 4:43 PM
Abe updated this revision to Diff 74751.Oct 14 2016, 4:47 PM
Abe updated this object.

added support for GCC [4.4 or higher required AFAIK]

Abe updated this object.Oct 14 2016, 4:48 PM
MatzeB edited edge metadata.Oct 14 2016, 5:03 PM

I am loosing track of the discussion as to why this is necessary. The big problem here however is cross compilation: you cannot assume that you can actually execute the results of this program as part of the build system configuration.

tools/FP-contraction_detection.c
37–41

AFAIK this is violating strict aliasing rules depending on which version of the C standard you use. I don't think any compiler would dare to miscompile it because the pattern is in widespread use. But correct way to do it however is something like:

static double u64_to_double(uint64_t x) {
  double d;
  memcpy(&d, &x, sizeof(x));
  return d;
}
48–53

I am not sure how exactly this is intended to be used, but usually it is far friendlier for scripting if you just do "return 0" or "return 1" in the main function. You could still have commandline switches if you really need multiple criteria or want a verbose mode with details on stdout/stderr.

Abe updated this object.Oct 17 2016, 9:09 AM
Abe edited edge metadata.
Abe updated this revision to Diff 74860.Oct 17 2016, 9:13 AM

implemented 2 good suggestions from MB ["u64_to_double" instead of union, exit code]

rengolin edited edge metadata.Dec 14 2016, 4:12 AM

I am loosing track of the discussion as to why this is necessary. The big problem here however is cross compilation: you cannot assume that you can actually execute the results of this program as part of the build system configuration.

I'm coming late to this discussion, sorry, I stopped getting emails from Phab for a while (no idea why).

I don't think that cross-compilation is a problem here. This is the test-suite (not LLVM), so we have to assume the compiled code runs on whatever target they were meant for.

I think this tool is interesting, but I'm not sure how we could use it in the current test-suite. Maybe Abe could expand on how we're expecting to use this on the remaining makefiles.

I have a number of inline comments, but mostly about style.

cheers,
--renato

tools/FP-contraction_detection.c
9

I'd rather have less verbose method names. My brain stops reading after the second underscore (or caps change).

Simpler names would be:

ContractDefaultSettings();
ContractPragmaNo();
ContractPragmaYes();
ContractOptNone();
45

This link needs a login. Please either explain what it is or find another link.

48–53

I agree and I was going to reply to that effect.

We can have both debug dumps and return values, but returning 0 for success and non-0 for failure is the accepted standard.

55

Since you're going to print stuff, why not be clear and verbose?

Since you're re-using the comparison below, why not give it a clear name, like:

FP_type Default = FMA_test_using_default_compiler_setting(A, B, C);
FP_type NoContract = FMA_test_with_pragma_for_NO_contraction(A, B, C);
FP_type YesContract = FMA_test_with_pragma_for_YES_contraction(A, B, C);
...
FP_type DefaultNoContract = (Default == NoContract);
FP_type DefaultYesContract = (Default == YesContract);
...
if (DEBUG) {
  printf("Default contract is: %s", (DefaultNoContract ? "No" : "Yes");
  ...
}
return ! (Default == NoContract == YesContract == NoOpt);

I am loosing track of the discussion as to why this is necessary. The big problem here however is cross compilation: you cannot assume that you can actually execute the results of this program as part of the build system configuration.

I'm coming late to this discussion, sorry, I stopped getting emails from Phab for a while (no idea why).

I don't think that cross-compilation is a problem here. This is the test-suite (not LLVM), so we have to assume the compiled code runs on whatever target they were meant for.

No! Experience shows that different people require various crazy combinations of simulators, ssh ing into a remote device, setting odd environment variables and other magic incantations to actually run target code when crosscompiling.

If possible I'd like to keep this logic out of the buildsystem and contained withing the lit runner. That means not running target code during the build.

No! Experience shows that different people require various crazy combinations of simulators, ssh ing into a remote device, setting odd environment variables and other magic incantations to actually run target code when crosscompiling.

Hum, you're right. I remember the test-suite used the compiler options for almost everything, so I assumed it would compile the tools with the same compiler, but that's obviously wrong.

Indeed, this makes it a no-starter for this patch. :(

--renato

Abe abandoned this revision.Dec 14 2016, 11:59 AM
Abe marked 2 inline comments as done.