This patch generates warning for invalid combination of '-mnan' and '-march' options, sets properly NaN encoding for a given '-march', and pass proper NaN encoding to the assembler.
Details
Diff Detail
Event Timeline
lib/Basic/Targets.cpp | ||
---|---|---|
5729 | That's my understanding. Although it's worth pointing out that we also accept microMIPS in mips32r2 at the moment even though it was added in mips32r3 as far as I know. For -mnan, I think we should add mips32r2 to the legacy-only list and explain the reason to anyone who asks about it. | |
5962–5974 | The diagnostics should mention that we're ignoring the request. | |
test/CodeGen/mips-unsupported-nan.c | ||
8 | We should check that the right warning is emitted for the right cases. |
lib/Basic/Targets.cpp | ||
---|---|---|
5729 | I think it is better to explicitly express 2008/legacy support status for each CPU. Let's consider the following code: enum NanMode { NanLegacy = 1, Nan2008 = 2 }; NanMode getSupportedNanMode() { return llvm::StringSwitch<int>(CPU) .Case("mips1", NanLegacy) .... .Case("mips32r2", NanLegacy | Nan2008) ... .Case("mips32r6", Nan2008) } ... IsNan2008 = getSupportedNanMode() == Nan2008; ... else if (*it == "+nan2008") { if (getSupportedNanMode() & Nan2008) IsNan2008 = true; else Diags.Report(diag::warn_target_unsupported_nan2008) << CPU; } | |
5964 | Why do we write a warning message right here instead to put it to the DiagnosticXXX.td file? |
New patch uploaded. The part of Preprocessor/init.c test is removed, because mips32r2 architecture is on the legacy-only list.
lib/Basic/Targets.cpp | ||
---|---|---|
5729 | It might be me only, but seeing a function that returns enum but can actually return non-enumerated value seems wrong (I am not saying it is illegal though). |
test/Preprocessor/init.c | ||
---|---|---|
4422 ↗ | (On Diff #22028) | In the same test there is a case that check __mips_nan2008 macro. |
lib/Basic/Targets.cpp | ||
---|---|---|
5729 | I think this is the main remaining comment. I agree in principle that enum types should have the value of one of the enum values. Like Petar, I don't think it's technically wrong though. Have you tried the -fsanitize=enum option that was suggested? Elsewhere, an integer type is used instead but given that there's only two values and I would be very surprised if we ever add more, we should probably just define NanBoth = 3 if it's a problem. | |
lib/Driver/Tools.cpp | ||
1119–1121 ↗ | (On Diff #22884) | Style nit: Unecessary braces around single-line if-statement. |
1126–1128 ↗ | (On Diff #22884) | Style nit: Unecessary braces around single-line if-statement. |
test/Preprocessor/init.c | ||
4422 ↗ | (On Diff #22028) | For reference: It's on line 4457 with the patch applied. |
test/Preprocessor/init.c | ||
---|---|---|
4419 ↗ | (On Diff #22884) | By the way, why do you decide to remove that test at all? Does it fail now? |
test/Preprocessor/init.c | ||
---|---|---|
4419 ↗ | (On Diff #22884) | Let's pass a correct set of arguments and check that +nan2008 switches on the __mips_nan2008 macro. And maybe additionally check that -nan2008 with the same options switches the macro off. |
lib/Basic/Targets.cpp | ||
---|---|---|
5729 | It seems -fsanitize=enum will allow all values up to a number that you get when you OR all possible valid enum values, so 3 in this case is OK, but not 4 for instance. |
lib/Driver/Tools.cpp | ||
---|---|---|
1119–1121 ↗ | (On Diff #22884) | Done. |
1126–1128 ↗ | (On Diff #22884) | Done. |
test/Preprocessor/init.c | ||
4419 ↗ | (On Diff #22884) | Done. |
According to the documentation, Has2008 field in FIR Register is optional as of R3. So, if I understand this correctly, mips32r2 always uses legacy encoding. Is that correct? If so, should we add mips32r2 case as well?