-
Notifications
You must be signed in to change notification settings - Fork 802
[SYCL] Device config file implementation #9846
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] Device config file implementation #9846
Conversation
AlexeySachkov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First iteration for now, but I will do a second pass, more comments are to be expected
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
| string aotToolchainOptions = options; | ||
| } | ||
|
|
||
| // This definition serves the only purpose of testing wether the aspect list defined in here and in SYCL RT matches |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are going to make clang driver to use list of targets defined here as a filter for supported targets, then we should probably somehow make sure that those are not exposed to user.
They at least should not be visible in any help and ideally should not be allowed to be set by a user at all. However, as a bare minimum, we could name them starting with double underscore or something like that to clearly indicate that this is not something to use by an end user.
| // This definition serves the only purpose of testing wether the deprecated aspect list defined in here and in SYCL RT matches | ||
| def : TargetInfo<"TestDeprecatedAspectList", 0, [AspectInt64_base_atomics, AspectInt64_extended_atomics, AspectUsm_system_allocator, AspectUsm_restricted_shared_allocations, AspectHost], [], "", "">; | ||
|
|
||
| def : TargetInfo<"TargetA", 1, [AspectCpu, AspectAtomic64], [8, 16], "ocloc", "devA">; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder, if we need to have an ability to pass "shortcuts" to list of aspects. What I mean here is that for most of devices there will be a set of "core" aspects, which is the same. To avoid repeating it for every target, we could say something like:
def AllUSMAspects: [AspectUsm_device_allocations, AspectUsm_host_allocations,
AspectUsm_shared_allocations, AspectUsm_system_allocations, AspectUsm_atomic_host_allocations
AspectUsm_atomic_shared_allocations];
def : TargetInfo<"TargetA", 1, [AspectCpu, AspectAtomic64. AllUSMAspects], [8, 16], "ocloc", "devA">;
However, I'm not sure how huge that "core" set of aspects would be or how huge would be groups which we can create, i.e. I'm not entirely sure if the repetition of the same aspect would be a real problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the current status of things, we can do:
defvar AllUSMAspects = [AspectUsm_device_allocations, AspectUsm_host_allocations,
AspectUsm_shared_allocations, AspectUsm_system_allocations, AspectUsm_atomic_host_allocations,
AspectUsm_atomic_shared_allocations];
def : TargetInfo<"Test", AllUSMAspects, []>;
defvar AspectList = [AspectCpu] # AllUSMAspects;
def : TargetInfo<"Test2", AspectList, []>;
def : TargetInfo<"Test3", [AspectCpu] # AllUSMAspects, []>;
| // The primary data table contains all the fields defined for this map. | ||
| OS << "std::map<std::string, " << Table.CppTypeName << "> " << Table.Name | ||
| << " = {\n"; | ||
| for (unsigned i = 0; i < Table.Entries.size(); ++i) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| for (unsigned i = 0; i < Table.Entries.size(); ++i) { | |
| for (unsigned I = 0; I < Table.Entries.size(); ++I) { |
| if (first) { | ||
| first = false; | ||
| second = true; | ||
| OS << LS << val << ", { "; | ||
| } else { | ||
| if (!second) { | ||
| OS << LS; | ||
| } | ||
| if (Field.IsList) { | ||
| val.insert(0, 1, '{'); | ||
| val.push_back('}'); | ||
| } | ||
| OS << val; | ||
| second = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic is a bit hard to understand at first glance. I think that there are some possibilities to do refactoring and simplify it, but it is hard to suggest without understanding the output here.
Which brings me to an important point: there are no tests for this new tablegen backend and we should add some. See llvm/test/TableGen for examples of existing ones
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
steffenlarsen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tiny nit, but otherwise I think it looks ready to go out of draft!
| if (!IsKey) | ||
| OS << TargetInfoElemSeparator << val; | ||
| else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I prefer having either all branches having bodies or none of them having.
| if (!IsKey) | |
| OS << TargetInfoElemSeparator << val; | |
| else { | |
| if (!IsKey) { | |
| OS << TargetInfoElemSeparator << val; | |
| } else { |
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
steffenlarsen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Runtime changes LGTM!
|
Friendly ping @intel/dpcpp-esimd-reviewers. |
|
|
||
| def : TargetInfo<"TargetA", [AspectCpu, AspectAtomic64], [8, 16], "ocloc", "devA", 1>; | ||
| def : TargetInfo<"TargetB", [AspectGpu, AspectFp16], [8, 16], "ocloc", "devB">; | ||
| def : TargetInfo<"TargetC", [AspectEmulated, AspectImage], [8, 16], "ocloc", "devC">; | ||
| def : TargetInfo<"TargetD", [AspectCpu, AspectFp64, AspectHost_debuggable], [8, 16], "ocloc", "devD", 1>; | ||
| defvar AspectList = [AspectCpu] # AllUSMAspects; | ||
| def : TargetInfo<"Test", AspectList, []>; | ||
| def : TargetInfo<"Test2", [AspectCpu] # AllUSMAspects, []>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that those are examples, but we should either remove them or move to comments before the commit.
I think it makes sense to leave one simple example of adding a new target here and one example, where list of aspects is produced as a combination of explicitly specified values + some other predefined list.
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
sarnex
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
llvm/lib/SYCLLowerIR/CMakeLists.txt LGTM from ESIMD side
Signed-off-by: Maronas, Marcos <marcos.maronas@intel.com>
maksimsab
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Prototype implementation for default Device Config File designed in #9371. Part of the testing is not present yet, nor is the ability to extend the default config file.