Introduce a compiler flag for cases when the user knows that the collapsed loop counter can be safely represented using at most 32 bits. This will prevent the emission of expensive mathematical operations (such as the div operation) on the iteration variable using 64 bits where 32 bit operations are sufficient.
Details
- Reviewers
ABataev caomhin - Commits
- rGa3afcf244531: [OpenMP] Add flag for preventing the extension to 64 bits for the collapse loop…
rL350758: [OpenMP] Add flag for preventing the extension to 64 bits for the collapse loop…
rC350758: [OpenMP] Add flag for preventing the extension to 64 bits for the collapse loop…
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 26180 Build 26179: arc lint + arc unit
Event Timeline
docs/OpenMPSupport.rst | ||
---|---|---|
119 | -fopenmp-optimistic-collapse | |
include/clang/Basic/LangOptions.def | ||
210 | Fix the description and the option in accordance with the option name | |
include/clang/Driver/Options.td | ||
1577 | Missed -fno... option | |
lib/Driver/ToolChains/Clang.cpp | ||
4429 | You need to change the processing taking into account -fno... option. | |
lib/Frontend/CompilerInvocation.cpp | ||
2848 | Also, need to check for -fno... option |
docs/OpenMPSupport.rst | ||
---|---|---|
119 | How about -fopenmp-use-32bit-collapse-parameter? |
include/clang/Basic/LangOptions.def | ||
---|---|---|
210 | The description accurately describes what Sema is doing. We allow an extension to up to 32 bits but no further. |
lib/Driver/ToolChains/Clang.cpp | ||
---|---|---|
4429 | fno_openmp_optimistic_collapse is not a frontend option. better to check for if (Args.hasFlag(options::OPT_fopenmp_optimistic_collapse, options::OPT_fno_openmp_optimistic_collapse, /*Default=*/false)) CmdArgs.push_back("-fopenmp-optimistic-collapse"); here rather than in the frontend. In the frontend, you can just check for the presence of the fopenmp_optimistic_collapse flag |
docs/OpenMPSupport.rst | ||
---|---|---|
119 | Alexey suggested we have no numbers in the flag name so we tried to find something that avoids that. I'm happy to give it a different name than optimistic collapse. |
docs/OpenMPSupport.rst | ||
---|---|---|
120 | Can you please clarify here what happens when the loop induction variables are already 64 bits. If any of them are already 64 bits, then we still use 64 bits overall? |
docs/OpenMPSupport.rst | ||
---|---|---|
120 | This flag is for the user to guarantee that the total size of the collapsed loops can be represented using at most 32 bits (regardless of the actual width of the individual loop induction variables). |
-fopenmp-optimistic-collapse