Cannot distinguish between host/device warnings and errors

[Pennycook]

I'm not sure if this issue is specific to kernel attributes or has wider applicability, but it can be difficult to understand whether host or device compilation is producing a given warning or error.

I'm most concerned about cases when only one of the compilers produces a warning, as below:

#include <CL/sycl.hpp>
using namespace sycl;

int main(int argc, char* argv[])
{
    queue q;
    q.submit([&](handler& cgh)
    {
        cgh.single_task<class test>([]() [[cl::intel_reqd_sub_group_size(8)]]
        {
        });
    });
}

reqd_sub_group_size.cpp:9:44: warning: 'intel_reqd_sub_group_size' attribute ignored [-Wignored-attributes]
        cgh.single_task<class test>([]() [[cl::intel_reqd_sub_group_size(8)]]
                                           ^
1 warning generated.

It is not clear from this message that the attribute was ignored on the host but respected on the device (or that this is expected behavior). Is there any way we could make this more obvious, like inserting the words "host" and "device" into the compilation output somewhere?

[keryell]

This is another argument for not using attributes directly but use C++ DSL constructions instead that can switch the the hidden attributes on/off behind the scene according to the context and also emit error messages at the library level instead of adding more and more cognitive load in the compiler...

[keryell]

A good example of a DSL approach seems https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/IntelFPGA/FPGAReg.md

[Pennycook]

I don't disagree, but I'm worried that hiding implementation details like this may still produce cases where the host and device compiler passes see different code and produce different warnings/errors.

I'll give some more thought to the reqd_sub_group_size attribute and what it would take to implement it at the library level. We'd need a solution that could modify the type of a functor, a lambda or a device function in an external translation unit.

[keryell]

Well, it is obviously up to the library implementer to come with the correct implementation and the righ error messages. :-)
For your last sentence, I made already some presentations inside the SYCL committee around 2016 and we discussed this again during last F2F meeting.
I summarized this in https://gitlab.khronos.org/sycl/Specification/issues/296