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

[C backend] Support CLANG eventually (in addition to ICC) #19

Open
rrnewton opened this issue May 19, 2014 · 0 comments
Open

[C backend] Support CLANG eventually (in addition to ICC) #19

rrnewton opened this issue May 19, 2014 · 0 comments
Assignees

Comments

@rrnewton
Copy link
Member

[Related to #20, which is the same thing for GCC.]

If the compiler backends in this repo become full featured enough to be usable, then it will eventually be important to support open source compilers as well as ICC. (Note that this backend is still far from complete -- currently, as of 5/19/14, there is only one full featured accelerate backend, CUDA, with a bunch of incomplete ones: llvm, opencl, ICC.)

This issue is a place to keep track which language features clang exposes that could be a substitute for the combination of cilk_for, pragma simd, and "elemental functions" that we use in the ICC backend.

Things seem to be coming along nicely for getting pragma simd in clang, as discussed here, with Intel's code available here. I haven't followed this closely and I don't know how close they are to merging with the clang trunk, much less getting that into a release.

The effort to add Cilk Plus to clang seems to be separate, but it also talks about pragma simd being supported.

If elemental functions are not supported we will need to change our current way of doing parallel loop codegen, where we store the real body of the loop out-of-line (as an elemental function) and make a call to it. Rather, we will just need to inline those bodies into the loop and do some extra alpha-renaming.

The idea for developing this new backend will probably be to further parameterize the existing EmitC.hs to support different variants. Which compiler to use is an implementation detail, so it probably does not deserve any new module namespace, rather, an environment variable or function parameter to control the existing parallel C/Cilk backend.

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

2 participants