-cl-denorms-are-zero no longer accepted in cc1 mode

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

-cl-denorms-are-zero no longer accepted in cc1 mode

David Blaikie via cfe-dev
I've been working on the mesa clover (OpenCL) frontend code.

it calls
clang::CompilerInvocation::CreateFromArgs
to create a clang compiler, but it passes the arguments it receives
from the OpenCL clBuildProgram API (-cl-denorms-are-zero) being one.
It currently doesn't strip any of those args out.

Now I can prepare the args and strip that one out if necessary, though
I'm not quite sure what I need to pass instead (since I want to
generate llvm bytecode to pass to the llvm->spirv translator).

But I wanted to give a heads up to other OpenCL implementers that
might have the same pattern (passing the options straight to clang),
but also check if this is what we expect.

Thanks,
Dave.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -cl-denorms-are-zero no longer accepted in cc1 mode

David Blaikie via cfe-dev
This may just be an artifact of how clover doesn't use the clang
driver at all, which might mean everyone else is fine and clover just
does it wrong.

But maybe someone else has done it wrong as well, so might appreciate
this headsup.

Dave.

On Wed, Nov 11, 2020 at 10:36 AM David Airlie <[hidden email]> wrote:

>
> I've been working on the mesa clover (OpenCL) frontend code.
>
> it calls
> clang::CompilerInvocation::CreateFromArgs
> to create a clang compiler, but it passes the arguments it receives
> from the OpenCL clBuildProgram API (-cl-denorms-are-zero) being one.
> It currently doesn't strip any of those args out.
>
> Now I can prepare the args and strip that one out if necessary, though
> I'm not quite sure what I need to pass instead (since I want to
> generate llvm bytecode to pass to the llvm->spirv translator).
>
> But I wanted to give a heads up to other OpenCL implementers that
> might have the same pattern (passing the options straight to clang),
> but also check if this is what we expect.
>
> Thanks,
> Dave.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -cl-denorms-are-zero no longer accepted in cc1 mode

David Blaikie via cfe-dev
Thanks for the heads up.

I guess this is related to the change that Matt has committed around a year ago: https://reviews.llvm.org/D69878

I think you should be able to achieve the same behaviour by using -fdenormal-fp-math-f32==ieee in cc1 mode. Many flags in OpenCL duplicate the existing compiler flags and therefore the idea is to keep them in the regular driver mode but with -cc1 we can just reuse the standard C/C++ interfaces.

However, I feel the documentation should be improved. Otherwise, I am not sure it is obvious what this flag corresponds to.

Cheers,
Anastasia


From: David Airlie <[hidden email]>
Sent: 11 November 2020 04:03
To: cfe-dev ([hidden email]) <[hidden email]>; [hidden email] <[hidden email]>; Anastasia Stulova <[hidden email]>
Subject: Re: -cl-denorms-are-zero no longer accepted in cc1 mode
 
This may just be an artifact of how clover doesn't use the clang
driver at all, which might mean everyone else is fine and clover just
does it wrong.

But maybe someone else has done it wrong as well, so might appreciate
this headsup.

Dave.

On Wed, Nov 11, 2020 at 10:36 AM David Airlie <[hidden email]> wrote:
>
> I've been working on the mesa clover (OpenCL) frontend code.
>
> it calls
> clang::CompilerInvocation::CreateFromArgs
> to create a clang compiler, but it passes the arguments it receives
> from the OpenCL clBuildProgram API (-cl-denorms-are-zero) being one.
> It currently doesn't strip any of those args out.
>
> Now I can prepare the args and strip that one out if necessary, though
> I'm not quite sure what I need to pass instead (since I want to
> generate llvm bytecode to pass to the llvm->spirv translator).
>
> But I wanted to give a heads up to other OpenCL implementers that
> might have the same pattern (passing the options straight to clang),
> but also check if this is what we expect.
>
> Thanks,
> Dave.


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev