azabaznov added inline comments.
================
Comment at: clang/lib/Basic/TargetInfo.cpp:360
+ // Set core features based on OpenCL version
+ for (auto CoreExt : clang::getCoreFeatures(Opts))
+ getTargetOpts().OpenCLFeaturesMap[CoreExt] = true;
----------------
Anastasia wrote:
> azabaznov wrote:
> > azabaznov wrote:
> > > Anastasia wrote:
> > > > azabaznov wrote:
> > > > > Anastasia wrote:
> > > > > > I still think the target map should be immutable and especially we
> > > > > > should not change it silently based on the language compiled even
> > > > > > if we have done it before but that caused incorrect behavior i.e.
> > > > > > successfully compiling for the architectures that didn't support
> > > > > > the features.
> > > > > >
> > > > > > If I look at existing targets they already set most of the core
> > > > > > features apart from 3d image writes. Perhaps it is reasonable to
> > > > > > just drop this code? I don't think it makes the issue worse, in
> > > > > > fact, I think it will make the behavior slightly better because now
> > > > > > a diagnostic will occur if there is an attempt to use the
> > > > > > unsupported feature although the diagnostic won't be the optimal
> > > > > > one. After all it will still remain the responsibility of the user
> > > > > > to get the right combination of a language version and a target.
> > > > > >
> > > > > > It would be reasonable however to introduce a diagnostic that would
> > > > > > report a mismatch between the language version and the hardware
> > > > > > support available. We report similar diagnostics in
> > > > > > `CompilerInvocation` already. But I don't think we have to do it in
> > > > > > this patch because it doesn't introduce any regression. We already
> > > > > > have a bug although the behavior of this bug will change. And
> > > > > > perhaps if we add `OpenCLOptions` as a part of `LangOpts` at some
> > > > > > point this will become straightforward to diagnose. However, I
> > > > > > suggest we add information about this issue in a FIXME or perhaps
> > > > > > this deserves a clang bug!
> > > > > > I still think the target map should be immutable and especially we
> > > > > > should not change it silently based on the language compiled
> > > > >
> > > > > I'm confused. I think we have agreed to unconditionally support core
> > > > > features for a specific language version. Did I miss something?
> > > > >
> > > > > > successfully compiling for the architectures that didn't support
> > > > > > the features.
> > > > >
> > > > > I like idea providing diagnostics in that case. Something like:
> > > > > "Warning: r600 target doesn't support
> > > > > cl_khr_3d_image_writes which is core in OpenCL C 2.0, consider using
> > > > > OpenCL C 3.0". I also think this should be done in a separate commit.
> > > > >
> > > > > > If I look at existing targets they already set most of the core
> > > > > > features apart from 3d image writes. Perhaps it is reasonable to
> > > > > > just drop this code?
> > > > >
> > > > > Oh, I haven't noticed that target set core features. For example
> > > > > //cl_khr_global_int32_base_atomics// is being set by NVPTX and
> > > > > AMDGPU, so I agree that this should be removed from target settings.
> > > > It is correct that the core features should be set unconditionally but
> > > > not in the `TargetInfo`. If core features are used for targets that
> > > > don't support them then it should not succeed silently as it does now
> > > > i.e. this means we need to know what is supported by the targets.
> > > >
> > > > Setting target features in `TargetInfo` is correct and should stay. We
> > > > should not change them here though because the language version doesn't
> > > > change the target capabilities. It can either expose or hide them from
> > > > the user but it should not modify targets. This is why `TargetInfo` is
> > > > immutable after its creation and this is how it should stay. I think
> > > > it's better if we remove the code here completely and introduce a
> > > > diagnostic in the subsequent patches that would just check that the
> > > > features required in the language version are supported by the target.
> > > >
> > > > If we do this then during the parsing we will only use feature
> > > > information from `OpenCLOptions` not the targets, but we will know that
> > > > the target have support of all the features because the check has been
> > > > performed earlier.
> > > I'm not generally against of removing core features set up, but I do have
> > > some questions and arguments:
> > >
> > > > It is correct that the core features should be set unconditionally but
> > > > not in the TargetInfo
> > >
> > > Just to make sure: where do you mean core features should be set
> > > unconditionally?
> > >
> > > > Setting target features in TargetInfo is correct and should stay. We
> > > > should not change them here though because the language version doesn't
> > > > change the target capabilities. It can either expose or hide them from
> > > > the user but it should not modify targets. This is why TargetInfo is
> > > > immutable after its creation and this is how it should stay
> > >
> > > I agree that `TargetInfo `should stay immutable during parsing, but for
> > > example here, in `TargetInfo::adjust`, current design already allows to
> > > change target capabilities based on language options, so I don't see what
> > > is conceptually wrong here.
> > >
> > > > If core features are used for targets that don't support them then it
> > > > should not succeed silently as it does now i.e. this means we need to
> > > > know what is supported by the targets.
> > >
> > > My main point in proposed design is that it is closer to specification:
> > > if target reports support for OpenCL C 2.0 then there is no need to extra
> > > checking for support of //core// features such as 3d image writes (we
> > > could also set for example generic address space and pipes as supported
> > > unconditionally later) as it is core in OpenCL C 2.0. Of course this
> > > should not be done silently; some diagnostics like fatal error "OpenCL C
> > > 2.0 is not supported in this target" or warning "core feature
> > > cl_khr_3d_image_writes is not supported in this target".
> > >
> > > then there is no need to extra checking for support of core features
> >
> > I mean extra checks in compiler, not in kernel code.
> > Just to make sure: where do you mean core features should be set
> > unconditionally?
>
> Why not to set them in `OpenCLOptions` directly? If you don't need any target
> properties for those why to do this in targets at all? After all
> `OpenCLFeaturesMap` will only be used to populate the `OpenCLOptions`. During
> the parsing, we will only use `OpenCLOptions` right?
>
> > I agree that TargetInfo should stay immutable during parsing, but for
> > example here, in TargetInfo::adjust, current design already allows to
> > change target capabilities based on language options, so I don't see what
> > is conceptually wrong here.
>
> Well, adjust was added to guarantee type widths for OpenCL. However, it has
> been introduced as a workaround and it still is. It has that fundamental
> problem of silently mutating the type without any guarantee of integrity i.e.
> what if targets doesn't support certain bitwidth? Then the code is just
> compiled incorrectly. There were various proposals to address this but it
> needs bigger refactoring - perhaps we should introduce the environment
> component for OpenCL. While for this use case the refactoring is too big and
> the workaround is very simple there are other places in clang where we could
> benefit from having such environment component in targets. So the gain might
> justify the effort. So in short unless there is a very good reason we should
> avoid using `adjust` because we still would like to remove it or at least
> remove OpenCL logic from it if possible.
>
> > My main point in proposed design is that it is closer to specification: if
> > target reports support for OpenCL C 2.0 then there is no need to extra
> > checking for support of core features such as 3d image writes (we could
> > also set for example generic address space and pipes as supported
> > unconditionally later) as it is core in OpenCL C 2.0. Of course this should
> > not be done silently; some diagnostics like fatal error "OpenCL C 2.0 is
> > not supported in this target" or warning "core feature
> > cl_khr_3d_image_writes is not supported in this target".
>
> I disagree spec never says that the standard should be supported on all
> targets even if they don't have the required functionality neither it
> regulate implementation aspects of mapping between language versions to
> targets.
>
> I think the design we should aim for:
> - Targets set supported HW features
> - Frontend verifies the features are present for the language version
> requested during compilation. If there is a mismatch a diagnostic should
> occur.
> - Frontend sets language options based on the requested language version and
> target features that are used during parsing to verify code correctness and
> create AST.
>
> Do you see any issue with this flow?
>
>
> Why not to set them in OpenCLOptions directly? If you don't need any target
> properties for those why to do this in targets at all? After all
> OpenCLFeaturesMap will only be used to populate the OpenCLOptions. During the
> parsing, we will only use OpenCLOptions right?
We also need to add preprocessor define for these extensions so we should look
into `OpenCLFeaturesMap` to add preprocessor defines because target could
disable core feature (see my comment below).
> I disagree spec never says that the standard should be supported on all
> targets even if they don't have the required functionality neither it
> regulate implementation aspects of mapping between language versions to
> targets.
Well, I think we start going in circles. This was actually my understanding of
the difference between //optional core// and //core// features - the latter is
required to be supported for all implementations from the version when it
becomes core (//unconditionally//). **Is my understanding right here**?
However, there is no clear stating about core features in the spec, this should
definitely be added.
> Do you see any issue with this flow?
This looks great. In terms of implementation I suggest doing the following:
core features are supported //unconditionally //for certain OpenCL C version,
but targets are allowed to disable them:
```
bool CompilerInstance::ExecuteAction(FrontendAction &Act) {
...
if (getLangOpts().OpenCL) {
getTarget().setCoreOpenCLFeatures(getLangOpts());
getTarget().setSupportedOpenCLOpts();
getTarget().setCommandLineOpenCLOpts();
}
// FIXME: We shouldn't need to do this, the target should be immutable once
// created. This complexity should be lifted elsewhere.
getTarget().adjust(getLangOpts());
...
}
...
void AMDGPUTargetInfo::setSupportedOpenCLOpts() {
// Core feature in CL 2.0, but not supported on amdgpu
Opts["cl_khr_3d_image_writes"] = false;
...
}
```
Of course proposed flow is relevant if and only if core features concept **is
correctly interpreted**. This will give more flexibility for targets and will
also allow to do diagnostics later. Also, this will help to unconditionally
support such core features for OpenCL C 2.0 as generic address space and pipes
etc. when implementing OpenCL C 3.0. What do you think?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D92277/new/
https://reviews.llvm.org/D92277
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
