- We were using substring matching for polly-only-func.
- Generalise this, so allow regexes as a parameter to polly-only-func.
Details
- Reviewers
efriedma jdoerfert Meinersbur gareevroman sebpop • zinob huihuiz pollydev grosser singam-sanjay - Commits
- rGe2699b572e99: [Polly] [NFC] [ScopDetection] Make `polly-only-func` perform regex scop name…
rPLO308875: [Polly] [NFC] [ScopDetection] Make `polly-only-func` perform regex scop name…
rL308875: [Polly] [NFC] [ScopDetection] Make `polly-only-func` perform regex scop name…
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Analysis/ScopDetection.cpp | ||
---|---|---|
285 ↗ | (On Diff #107676) | [Serious] Don't use llvm_unreachable to reliably abort. In release-builds something unpredictable will happen, e.g. remove the R.isValid test altogether because there is just one outcome with defined behavior. |
Thanks Michael!
lib/Analysis/ScopDetection.cpp | ||
---|---|---|
285 ↗ | (On Diff #107676) | Right. I missed this one! |
lib/Analysis/ScopDetection.cpp | ||
---|---|---|
285 ↗ | (On Diff #107676) | What does:
mean? If I cannot guarantee llvm_unreachable will abort, would returning false be acceptable? I really want to keep the error logging because I can forsee myself spending a good couple of minutes trying to debug this at some point in the future :). |
[NFC wrt patch] return false indicating failure of regex match if regex did not compile
lib/Analysis/ScopDetection.cpp | ||
---|---|---|
285 ↗ | (On Diff #107676) | @Meinersbur does this look okay? |
lib/Analysis/ScopDetection.cpp | ||
---|---|---|
285 ↗ | (On Diff #107676) | Yes, because I don't want it to "reliably abort", I want it to abort in debug builds. |
My feeling is that the user-observable behavior of debug and non-debug builds should be indentical. If this is not the case, I would see this as a bug.
@Meinersbur: I would like an LGTM on your part to be comfortable with upstreaming this.
lib/Analysis/ScopDetection.cpp | ||
---|---|---|
285 ↗ | (On Diff #107676) | A llvm_unreachable means that the programmer thinks that that line can under no circumstance can execute. Executing it is undefined behaviour. That the program terminates with a message is a courtesy of the Debug build. In release builds, the compiler can remove the entire branch because it thinks there is no execution with defined behaviour that executes it. See the __builtin_unreachable section at https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html . Relevant comments in the llvm sources: /// LLVM_BUILTIN_UNREACHABLE - On compilers which support it, expands /// to an expression which states that it is undefined behavior for the /// compiler to reach this point. Otherwise is not defined. /// In NDEBUG builds, becomes an optimizer hint that the current location /// is not supposed to be reachable. On compilers that don't support /// such hints, prints a reduced message instead. /// /// Use this instead of assert(0). It conveys intent more clearly and /// allows compilers to omit some unnecessary code. So llvm_unreachable is only a substitute for assert(false). In C programs, use abort() to exit the program under an error condition. The LLVM command line paser calls report_fatal_error() with malformed user input. I suggest to do the same. |
lib/Analysis/ScopDetection.cpp | ||
---|---|---|
285 ↗ | (On Diff #107676) | You can also drop the braces around a single statement body |