Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of static inline functions in headers #46

Open
rbehrends opened this issue Sep 5, 2017 · 0 comments
Open

Handling of static inline functions in headers #46

rbehrends opened this issue Sep 5, 2017 · 0 comments

Comments

@rbehrends
Copy link
Contributor

Recently, GAP headers were rewritten to use static inline functions instead of macros for functionality such as ELM_PLIST() and ADDR_OBJ(). Ward assumes that every function takes care of the appropriate guards itself; because almost all object accesses are now embedded in such static inline functions, no guards are generated at all.

There are two principal options to resolve this issue.

  1. Add guards to static inline functions in header files, too. While this would be comparatively easy (one would just have to add guards to header files and not just .c files), it would leave a lot of optimization potential on the table, as clang/gcc do not know that (for example) guards are loop-invariant code and thus can be moved out of loops. This solution would necessitate teaching C compilers about that aspect of guards, and that may not even be possible. On the other hand, it would allow us to (1) get better performance where Ward misses out on such optimizations and (2) potentially get rid of Ward entirely.
  2. The alternative is to teach Ward about properly processing static inline functions. The basic infrastructure for that is already in place (from earlier versions of Ward, which attempted to do just that for all functions). This infrastructure could be resurrected and applied to Ward, though that would also be a fair amount of work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant