From Open64 Wiki
Use of this page
- The document is meant as a guideline for Open64 developers. The purpose is to encourage good software practice. While we want to keep existing practices in open64 that have been proven useful, it is also important to allow modern software practices. We expect people to use this document as a guideline. We also assume that open64 developers are well versed in basics of C or C++ coding conventions and pitfalls. This is not meant to be an exhaustive list of coding style, use this to complement your good programming practice.
- Stay consistent with existing style and convention of the source file
- For each source file, the style should be consistent (e.g. indentation, naming convention, braces, spacing, …)
maximize code reuse
- Maximize code sharing and reuse when possible
minimize compilation time
- Minimize compilation time
enable compiler to optimize
- Word of caution: Instead of writing obscure, heavily hand tuned code that is hard to read, as compiler writers, the code should be such that we allow the compiler maximum opportunity to optimize.
C++ coding style
- Use C++ coding style whenever possible, unless constrained by existing infrastructure.
- Open64 has traditionally discouraged inheritance and virtual functions, this is still the case today
- Use of static is discouraged. In fact, inside WOPT, other than a few variables (such as error code), static is NOT ALLOWED from the very beginning when WOPT was developed
- Use of ifdef or "if defined" is discouraged. Try use different practices to accomplish what is needed.
no compatibility breaking
- While we do not guarantee compatibility between compiler builds, whenever possible, avoid breaking compatibility. E.g. if a new operator is introduced, add at the end.
- Use of assertions is strongly recommended
- Use type name defined in Open64 ecosystem instead of C++ standard type. E.g. we encourage use of INT32 over int.
- For the basic styles such as naming, indentation, declaration, include, … we have included a source file and it's include file in Appendix.
- Additional general coding style can be found in appendix A and B. They are written as cxx and .h file. We think real examples are the best to illustrate the recommended convention.
- The goal is to enable automatic tools to quickly find out the file, function, basic block, expression, instruction that exhibits a specific problem at hand. Quality, price and users testimonials are those 3 factors that I took into consideration while choosing appropriate writing service to write my essay. I hold my eye on supremeessays.com and have never regretted my choice. They provided me with custom papers of the highest quality. Coding practice should be so that this is possible. This could include choosing the algorithm that enables this over one that cannot (e.g. SSAPRE vs. bit-vector PRE). There should not be assumptions across phases. This is a pre-condition for more accurate automatic triage tool.
option to control
- Each optimization, phase must have option that can be turned off. When applicable, allow Open64's built-in mechanism for binary search to identify the offending instance.
no customized tracing
- Open64 has well defined 'tracing' mechanism with controls on file, function, BB level granularity; plus many other whistles and improvements through time (i.e., Get_Trace). Use of new tracing mechanism is not allowed. This tracing mechanism should not be used as options to turn on/off optimization.
- Open64 has well defined FmtAssert/Is_True/Fatal/DefWarn/… mechanism that is also tied with debug vs. production (or release) build of the compiler. Other forms of "assertion", including the "assert" that comes with C/C++ language spec is not allowed.
Macro vs. Inline functions
inline instead of macro
- Whenever possible, use inline functions instead of macros.
- Use inline/member functions instead of direct field access.
test case for bug fix
- Each bug fix should have small test case checked into open64 regression suite
self contained features
- Keep new features self contained whenever possible
no assumption across
- No assumption across different phases
- For each optimization, the IR must remain semantically the same before and after the transformation. E.g. the IR should not need optional expressions to maintain the same semantics.
- Although retargetability is not the original design goal, the compiler has been retargeted to more than four different targets. This requirement is becoming more important. We intend to improve this area moving forward.
- Use of ifdef or “if defined” is discouraged. Today, the code is littered with them, obstructing readability, hence maintainability of the code. A better way is to define a flag for target-specific property and then set the flag in target-specific sub-files.
- Appendix A (coding_convention.h)
sample cxx file
- Appendix B (coding_convention.cxx)