[cfe-dev] -cl-denorms-are-zero no longer accepted in cc1 mode

[Anastasia Stulova 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 <airlied at redhat.com>
Sent: 11 November 2020 04:03
To: cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>; ben.ashbaugh at intel.com <ben.ashbaugh at intel.com>; Anastasia Stulova <Anastasia.Stulova at arm.com>
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 <airlied at redhat.com> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201111/b7dec971/attachment-0001.html>