Skip to content

Document the -fsycl-targets flag #1191

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.

Sign up for GitHub

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

Jump to bottom
Closed
fwyzard opened this issue Feb 26, 2020 · 9 comments
Closed

Document the -fsycl-targets flag #1191

fwyzard opened this issue Feb 26, 2020 · 9 comments
Assignees
@mdtoguchi
Labels
Documentation Missing documentation for the code, compiler or runtime features, etc.

Comments

@fwyzard
Copy link
Contributor

fwyzard commented Feb 26, 2020

clang++ --help says very little about -fsycl-targets:

  -fsycl-targets=<value>  Specify comma-separated list of triples SYCL offloading targets to be supported

Digging through some code, documentation, and -sycl-help I found five possible targets:

  • spir64-unknown-unknown-sycldevice: OpenCL backend (default target ?)
  • spir64_gen-unknown-unknown-sycldevice: OpenCL backend, with ahead-of-time compilation for Intel NEO driver and Gen "X" GPUs (via ocloc)
  • spir64_x86_64-unknown-unknown-sycldevice: OpenCL backend, with ahead-of-time compilation for Intel CPUs (via opencl-aot)
  • spir64_fpga-unknown-unknown-sycldevice: OpenCL backend, with ahead-of-time compilation for Intel FPGAs (via aoc)
  • nvptx64-nvidia-cuda-sycldevice: CUDA backend

Is there a way to list all supported targets ?

Does it make any difference if one uses e.g. spir64-unknown-unknown-sycldevice or spir64-unknown-linux-sycldevice ?
@fwyzard
Copy link
Contributor Author

fwyzard commented Feb 26, 2020

In fact, it looks like nvptx64---sycldevice and spir64---sycldevice work just as well ?

@AlexeySachkov AlexeySachkov added the Documentation Missing documentation for the code, compiler or runtime features, etc. label Feb 27, 2020
@shssf
Copy link

shssf commented Aug 24, 2020 •
edited
Loading

Is there a way to list all supported targets ? For example -fsycl-targets=list to see all supported options

vmaksimo pushed a commit to vmaksimo/llvm that referenced this issue Sep 6, 2021
@MrSidims @vmaksimo
Improve LLVM annotations translation to SPIR-V (intel#1191)
703cd0a 
https://reviews.llvm.org/D88645 introduces additional parameter
to var/ptr/global annotation instruction, which can be set by
clang::annotation attribute that has variadic constant expression
argument. Right now we can't translate it properly and an extension
is being discussed, but yet we need a W/A for this. As a W/A the
current patch makes this argument (in case if it is const int) be
translatable as a string put in UserSemantic decorations, so the
IL flow is looking like this:
Annotation in source-code:
[[clang::annotate("custom", 30, 60)]] int *Var;

LLVM IR before:
 @.str = private unnamed_addr constant [7 x i8] c"custom\00"
 @.args = private unnamed_addr constant { i32, i32 } { i32 30, i32 60 }
 // ...
 call void @llvm.var.annotation(i8* ...,
       i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str, i32 0, i32 0),
       i8* ... , i32 ..., i8* bitcast ({ i32, i32 }* @.args to i8*))
 // ...

SPIR-V:
  Decorate %GEP% UserSemantic "custom: 30, 60"

LLVM IR after:
  @3 = private unnamed_addr constant [15 x i8] c"custom: 30, 60\00"
  // ...
  call void @llvm.var.annotation(i8* ..., i8* getelementptr inbounds (
      [15 x i8], [15 x i8]* @3, i32 0, i32 0), i8* ..., i32 ..., i8* undef)
  // ...

As you see the annotation remains to be a string after the translation. It's
done so because we wouldn't be able to distinguish
[[clang::annotate("custom", 30, 60)]] from [[clang::annotate("custom, 30, 60")]]
as they both would result in the same UserSemantic decoration.

Also this patch brings a bit of refactoring of add Intel FPGA decoration functions,
since their infrustructure can (and should) be reused here, solving an issue of
incorrect allowed FPGA memory SPIR-V extensions processing.

TODO:
1. Replace this W/A with an extension, when it's ready;
2. Global annotation instruction isn't handled properly yet, its handling requires even
   more refactoring, which I plan to do, when the extension is ready.

Signed-off-by: Dmitry Sidorov <[email protected]>

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@869f703
@AGindinson AGindinson removed their assignment Jan 26, 2022
@AGindinson
Copy link
Contributor

In view of the extensive existing documentation at https://www.intel.com/content/www/us/en/develop/documentation/oneapi-dpcpp-cpp-compiler-dev-guide-and-reference/top.html, I would suggest re-assessing whether the issue is still relevant.

@mirenradia
Copy link

In view of the extensive existing documentation at https://www.intel.com/content/www/us/en/develop/documentation/oneapi-dpcpp-cpp-compiler-dev-guide-and-reference/top.html, I would suggest re-assessing whether the issue is still relevant.

I think this only documents the targets available in the official releases. In theory, one could build from source with a different set of targets (e.g. nvptx64-nvidia-cuda).

@KornevNikita
Copy link
Contributor

KornevNikita commented May 17, 2024 •
edited
Loading

Hi! There have been no updates for at least the last 60 days, though the ticket has assignee(s).

@mdtoguchi, could I ask you to take one of the following actions? :)

  • Please provide an update if you have any (or just a small comment if you don't have any yet).
  • OR mark this issue with the 'confirmed' label if you have confirmed the problem/request and our team should work on it.
  • OR close the issue if it has been resolved.
  • OR take any other suitable action.

Thanks!

@github-actions GitHub Actions
Copy link
Contributor

Hi! There have been no updates for at least the last 60 days, though the issue has assignee(s).

@mdtoguchi, could you please take one of the following actions:

  • provide an update if you have any
  • unassign yourself if you're not looking / going to look into this issue
  • mark this issue with the 'confirmed' label if you have confirmed the problem/request and our team should work on it
  • close the issue if it has been resolved
  • take any other suitable action.

Thanks!

@AlexeySachkov
Copy link
Contributor

At least for builds made from intel/llvm sources, list of available targets and more detailed documentation for the -fsycl-targets can be found in our User Manual

Does it make any difference if one uses e.g. spir64-unknown-unknown-sycldevice or spir64-unknown-linux-sycldevice?

Since that issue was reported we have completely dropped sycldevice suffix and you can now omit unknown-unknown part of the triple as well. Most likely we ignore those elements of the triple, but recommendation would be not to put anything random in them and instead just use a shortcut spir64.

Is there a way to list all supported targets ? For example -fsycl-targets=list to see all supported options

@mdtoguchi, do you think that is something we can implement? I'm not entirely sure how -fsycl-targets is implemented and whether we do any early validation of it

@mdtoguchi
Copy link
Contributor

For -fsycl-targets we do some validation of the targets given so it would not be a stretch to see if we can emit some information that provides a list of valid targets. We would just need to find a reasonable option to emit the output.

@AlexeySachkov AlexeySachkov mentioned this issue Oct 9, 2024
Open
@AlexeySachkov
Copy link
Contributor

I think that the documentation part of the question can be considered resolved. I've outlined the request to add a way to display all possible targets through a flag into #15641 to track it separately. Having that said, I'm going to close the issue as complete, but please let us know if there are still questions/comments/concerns about anything

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mdtoguchi mdtoguchi

Labels
Documentation Missing documentation for the code, compiler or runtime features, etc.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@fwyzard @AlexeySachkov @shssf @mirenradia @KornevNikita @AGindinson @mdtoguchi