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

[SYCL][Driver] Refactor xocc driver script back into the LLVM Driver/ToolChain #73

Open
agozillon opened this issue Nov 8, 2019 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@agozillon
Copy link
Contributor

I'm not sure how interested you'd (@keryell) be in changing this, but I thought I'd open up an issue in any case as a general reminder that it can be done. Feel free to close it though.

It seems the Intel SYCL team had a similar problem to us in that the Clang driver doesn't really play well with unknown number of outputs from a tool step as it can't predict the future and the commands are set in stone before the commands are executed. So if your tools don't support File Lists (which xocc doesn't seem to for the moment) as an input you have a problem. So like you've noticed they made this tool: intel/llvm#793

I think you could probably use this to get rid of at least part of the xocc driver script if you ever wanted to. Part of the reason the script exists is because you don't know how many xocc compilation invocations you need to make until you've executed the optimization passes on the module (as you need to execute one per kernel) so you can't generate the right number of ConstructJob calls to xocc at the time the Clang Driver wants to know what jobs need to be done.

You could maybe circumvent that issue by generating a list of files from the Optimization passes (or another tool) and feeding it to a ConstructJob of Intel's new tool that will call an xocc invocation per item in the list of files (kernel names or paths to each kernel).

Refactoring the linker step out of the script and back into the Clang driver is likely trivial in comparison.

I think I previously mentioned something less well thought out than this, so it's nice to see a possible solution to it! Maybe there is a more trivial solution I'm overlooking though or I'm misunderstanding the tools purpose.

Perhaps a worthy avenue to look at if the Xilinx SYCL FPGA ToolChain ever became less research oriented and was looking at upstreaming as I imagine using a (hopefully) pre-existing tool would go down better than adding the dependency of a script.

@agozillon agozillon added enhancement New feature or request question Further information is requested labels Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant