[cfe-dev] [RFC] New file extension for compiling C++ for OpenCL sources

Wed Mar 17 10:35:09 PDT 2021

Just to summarize - it seems that both '.cppcl' and '.clcpp' would be viable
options.

While this survey shows that the preference is slightly towards '.cppcl', we
have discussed this further on the review (https://reviews.llvm.org/D96771) and
it seems '.clcpp' would be more in alignment with '-cl-std' option that accepts
"cl" for OpenCL C and "clc++" for C++ for OpenCL. Therefore the proposed
interface would be as follows:

  *   OpenCL C has default '-cl-std=cl' and file extension '.cl'.
  *   C++ for OpenCL has default '-cl-std=clc++' and file extension '.clcpp'.

Note that the extension '.clc++' would be even more aligned with '-cl-std' but
however clang uses '.cpp' as the main extension for C++.

Let me know if you have any more input.

Thanks,
Anastasia

________________________________
From: Andrzej Warzynski <Andrzej.Warzynski at arm.com>
Sent: 19 February 2021 16:02
To: Anastasia Stulova <Anastasia.Stulova at arm.com>
Cc: cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [RFC] New file extension for compiling C++ for OpenCL sources

I think that TY_CLXX could be a bit confusing at this point. It makes no
real difference in the compiler driver at this moment (i.e. OpenCL C and
OpenCL C++ are treated identically regardless).

Separately, in the frontend driver, you can set the language to
`OpenCLCXX` based on the file extension. This way you get rid of the
need for `-cl-std=clc++` as OpenCL C++ files can be identified based on
the extension in the frontend. Basically what you do you in your patch :)

So yes, I would leave TY_CLXX out for now. [*]

As for file extensions - this change makes `-cl-std=clc++` a rather
obscure flag (for e.g. compiling *.cl files as OpenCL C++ files). I
think that what you are proposing is a great improvement, thank you!

FWIW, there is way too many flags in Options.td. Less is more :)

-Andrzej

[*] Unless I've missed something and it's actually needed.

On 18/02/2021 16:47, Anastasia Stulova wrote:
> FYI in my initial patch (https://reviews.llvm.org/D96771
> <https://reviews.llvm.org/D96771>), I am adding TY_CLXX,
> but it was done mainly for the orthogonality rather than any functionality.
>
> In a long term, I imagine the OpenCL C and C++ for OpenCL can start
> diverging
> in their setup and then we would need more changes in the driver. The only
> example I can think of right now is the standard libraries. But however,
> we don't
> add any special new libraries for C++ mode yet. Do you think it is
> better to leave
> this functionality out until we have an actual use case?
>
> As for the other extensions (e.g. header files, pre-processed output,
> etc) we haven't
> used any different ones from the standard C/C++ ones up to now. I
> imagine they are
> not extremely popular and I also find adding too many of them making things
> complicated and confusing too. So I don't imagine we would want to add
> them into
> driver support.
> ------------------------------------------------------------------------
> *From:* cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Andrzej
> Warzynski via cfe-dev <cfe-dev at lists.llvm.org>
> *Sent:* 18 February 2021 12:28
> *To:* cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] [RFC] New file extension for compiling C++ for
> OpenCL sources
> I think that there are two things. First, the file extensions on their
> own. I think that it's fine to introduce e.g. .clcxx/.clcpp and make
> them map to e.g. TY_CL. This won't change much from the perspective of
> the driver, but end-users could start using and getting used to it. And
> adoption in IDEs/CMake could start as well.
>
> The other thing is internal representation in clangDriver. Do we need to
> introduce TY_CLXX on top of TY_CL? I get the impression that TY_CL
> should be fine for now. There is TY_C and TY_CXX and you will find many
> places in the driver where the input type (e.g. TY_C vs TY_CXX vs
> TY_Fortran) affects the logic (e.g. which headers/libs/search-paths to
> include).
>
> For Fortran, extensions are used to differentiate between:
>     * fixed-form, free-form
>     * pre-processed, not-pre-processed
>     * various language standards
> (personally I find this very confusing). So the extensions matters a lot
> and affects various stages of the compilation (e.g. preprocessing,
> parsing & sema). Some of the resulting logic lives in clangDriver, some
> of it in the new Flang frontend driver. Do you think that we will need
> such logic to differentiate between C and C++ OpenCL source files?
>
> I get the impression that in order to support what's currently required,
> we don't need TY_CLXX just yet. But I'm also an OpenCL outsider and I
> might be missing something here :)
>
> -Andrzej
>
>
> On 18/02/2021 11:40, Anastasia Stulova via cfe-dev wrote:
>> Good point - another similar example would be the syntax highlight
>> in the IDEs or editors that frequently use the file extensions too.
>>
>> ------------------------------------------------------------------------
>> *From:* cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Stephen
>> Kelly via cfe-dev <cfe-dev at lists.llvm.org>
>> *Sent:* 17 February 2021 22:12
>> *To:* cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
>> *Subject:* Re: [cfe-dev] [RFC] New file extension for compiling C++ for
>> OpenCL sources
>>
>> On 17/02/2021 16:36, Arthur O'Dwyer via cfe-dev wrote:
>>> FWIW, as a complete outsider, as a complete non-user of OpenCL (but a
>>> heavy user of C++), I don't see why a new filename extension is a good
>>> thing.
>>
>>
>> I'm also an opencl outsider.
>>
>> However, if opencl files are to be detected by a buildsystem like (but
>> not limited to) cmake, then a file extension is a good thing. Consider
>> this cmake code:
>>
>> cmake_minimum_required(VERSION 3.10)
>>
>> project(testproj C CXX OBJCXX OBJC)
>>
>> add_library(test
>>  ï¿½ï¿½ï¿½ï¿½ test.cpp
>>  ï¿½ï¿½ï¿½ï¿½ test.c
>>  ï¿½ï¿½ï¿½ï¿½ test.m
>>  ï¿½ï¿½ï¿½ï¿½ test.mm
>> )
>>
>>
>> CMake detects the source-language of each source file and uses the
>> appropriate driver and language compile option for each one.
>>
>> With a file extension for opencl, CMake could use the appropriate
>> driver/option for that language too. Without a distinct file extension
>> for it, the user would have to tell cmake what the language is, which is
>> inconvenient for the user.
>>
>> Thanks,
>>
>> Stephen.
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210317/4b3cb804/attachment-0001.html>