You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: