chapel
chapel copied to clipboard
chapel-lang
comparisons between uint and 0 aren't folded by the compiler
Feature request
Summary of Problem
Given a comparison between a uint and 0 that is known to always be true by definition such as 'a > 0' or 'a >= 0', I believe the compiler should param fold this conditional as it does with other obvious facts. It doesn't currently at present because the overload that handles this case returns 'true' along one branch (when the other arg is a param 0) and calls the execution time comparison in the other branch; so the routine can't be a param routine and can't be folded.
A potential fix is to break the routine into two using a where clause to disambiguate and making the obvious case a param function and the other case not. But this runs into bugs in our handling of where clauses which is another issue (#5236).
Steps to Reproduce
Source Code:
config var x: uint;
if (x < 0) then
compilerError("This should never happen");
Compile command:
chpl foo.chpl
Execution command:
./a.out
Configuration Information
- Output of
chpl --version: 1.14.0.a771ec7 - Output of
$CHPL_HOME/util/printchplenv --anonymize: N/A - Back-end compiler and version, e.g.
gcc --versionorclang --version: N/A - (For Cray systems only) Output of
module list: N/A
PR #5277 makes an attempt to fix this issue using the new where clause fixes introduced in PR #5275 but is currently failing with three tests.
PR #11570 has some related changes. See https://github.com/chapel-lang/chapel/pull/11570#discussion_r230961816
Here is a link to the test we'd like to get to pass for this issue to close: https://github.com/chapel-lang/chapel/pull/5277/files#diff-c60cb09d88210e77db2f5c34662d065d
#25529 implements this specifically for <.
I am leaving this issue open as a request for similar changes to other operators: <= >= > == !=.
I hate to look a gift horse in the mouth (particularly one that I requested), but I wonder whether it's worse to support thse foldings only for < without adding the symmetric support to >, <, >=, and >=... (just from a non-orthogonality perspective)
@bradcray I do not have an answer to the "is it worse" question. My thinking is (a) if we like what I did in #25529 then we can do the same for the other operators, and (b) feel free to back out #25529 pending (a), if desired.