[clang] 23058f9 - [OPENMP]Do not use RTTI by default for NVPTX devices.
Alexey Bataev via cfe-commits
cfe-commits at lists.llvm.org
Wed Jan 15 15:09:49 PST 2020
And I disabled it only for device side, which is NVPTX, no? Can host
side target class report that the target is NVPTX? If you look at the
patch, it disable RTTI only if current triple is NVPTX. Can it be true
for the host?
-------------
Best regards,
Alexey Bataev
15.01.2020 1:06 PM, Artem Belevich пишет:
>
>
> On Wed, Jan 15, 2020 at 2:52 PM Alexey Bataev <a.bataev at outlook.com
> <mailto:a.bataev at outlook.com>> wrote:
>
> 1. The problem is that it does not produce errors,
>
> ATM, it does produce errors when it's disabled.
>
> it leads to the emission of some declaration that cannot be
> resolved by the linker. This what I was trying to avoid.
>
> I'm OK with disabling it on device, but it should be done in a way to
> keep RTTI in the host code working.
>
> E.g. this code should compile: https://godbolt.org/z/Gzsrof
> It still has your original change, so clang compilation fails. It does
> not with NVCC.
>
> 2. Yes, I did not disable it on the host side, just for the device
> side. I disabled it only for NVPTX target, which is the device.
>
> It's fine to disable it for code generated for the target. However,
> the front-end needs to be able to deal with the host-side code where
> it is OK to use RTTI.
>
> --Artem
>
>
>
>
> -------------
> Best regards,
> Alexey Bataev
>
> 15.01.2020 12:49 PM, Artem Belevich пишет:
>> Thank you.
>>
>> In general, RTTI should probably be treated similar to how we
>> deal with inline assembly and ignore errors if they are in the
>> code that we're not going to codegen during this side of
>> compilation. E.g. during host-side compilation we don't complain
>> about GPU-side registers in inline assembly that x86 target is
>> not aware of.
>>
>> Disabling RTTI altogether on device side makes it impossible to
>> use in any host-side CUDA because RTTI code will be seen by the
>> device-side compiler, which will promptly fail, which is exactly
>> what happened in this case -- host-side template that relied on
>> RTTI failed during device-side compilation:
>>
>> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/arena.h#L536
>> google/protobuf/arena.h:536:15: error: use of typeid requires -frtti
>> AllocHook(RTTI_TYPE_ID(T), n);
>> ...
>> 2 errors generated when compiling for sm_60.
>>
>> --Artem
>>
>> On Wed, Jan 15, 2020 at 2:36 PM Alexey Bataev
>> <a.bataev at outlook.com <mailto:a.bataev at outlook.com>> wrote:
>>
>> Sure, will revert it ASAP.
>>
>> -------------
>> Best regards,
>> Alexey Bataev
>>
>> 15.01.2020 12:26 PM, Artem Belevich пишет:
>>> Alexey,
>>>
>>> This breaks compilation of our cuda code which happens to
>>> transitively include protobuf headers.
>>> Can you, please, revert it for now until we figure out how
>>> RTTI should be handled?
>>>
>>> --Artem
>>>
>>> On Tue, Jan 14, 2020 at 3:15 PM Alexey Bataev via
>>> cfe-commits <cfe-commits at lists.llvm.org
>>> <mailto:cfe-commits at lists.llvm.org>> wrote:
>>>
>>>
>>> Author: Alexey Bataev
>>> Date: 2020-01-14T18:12:06-05:00
>>> New Revision: 23058f9dd4d7e18239fd63b6da52549514b45fda
>>>
>>> URL:
>>> https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda
>>> DIFF:
>>> https://github.com/llvm/llvm-project/commit/23058f9dd4d7e18239fd63b6da52549514b45fda.diff
>>>
>>> LOG: [OPENMP]Do not use RTTI by default for NVPTX devices.
>>>
>>> NVPTX does not support RTTI, so disable it by default.
>>>
>>> Added:
>>> clang/test/Driver/openmp-offload-gpu.cpp
>>>
>>> Modified:
>>> clang/lib/Driver/ToolChain.cpp
>>>
>>> Removed:
>>>
>>>
>>>
>>> ################################################################################
>>> diff --git a/clang/lib/Driver/ToolChain.cpp
>>> b/clang/lib/Driver/ToolChain.cpp
>>> index cab97b1a601a..3ebbd30195b3 100644
>>> --- a/clang/lib/Driver/ToolChain.cpp
>>> +++ b/clang/lib/Driver/ToolChain.cpp
>>> @@ -68,7 +68,8 @@ static ToolChain::RTTIMode
>>> CalculateRTTIMode(const ArgList &Args,
>>> }
>>>
>>> // -frtti is default, except for the PS4 CPU.
>>> - return (Triple.isPS4CPU()) ? ToolChain::RM_Disabled :
>>> ToolChain::RM_Enabled;
>>> + return (Triple.isPS4CPU() || Triple.isNVPTX()) ?
>>> ToolChain::RM_Disabled
>>> + :
>>> ToolChain::RM_Enabled;
>>> }
>>>
>>> ToolChain::ToolChain(const Driver &D, const
>>> llvm::Triple &T,
>>>
>>> diff --git a/clang/test/Driver/openmp-offload-gpu.cpp
>>> b/clang/test/Driver/openmp-offload-gpu.cpp
>>> new file mode 100644
>>> index 000000000000..9da7308506ae
>>> --- /dev/null
>>> +++ b/clang/test/Driver/openmp-offload-gpu.cpp
>>> @@ -0,0 +1,20 @@
>>> +///
>>> +/// Perform several driver tests for OpenMP offloading
>>> +///
>>> +
>>> +// REQUIRES: clang-driver
>>> +// REQUIRES: x86-registered-target
>>> +// REQUIRES: powerpc-registered-target
>>> +// REQUIRES: nvptx-registered-target
>>> +
>>> +///
>>> ###########################################################################
>>> +
>>> +/// PTXAS is passed -c flag by default when offloading
>>> to an NVIDIA device using OpenMP
>>> +/// Check that the flag is passed when
>>> -fopenmp-relocatable-target is used.
>>> +// RUN: %clangxx -### -fopenmp=libomp
>>> -fopenmp-targets=nvptx64-nvidia-cuda \
>>> +// RUN: -save-temps -no-canonical-prefixes %s
>>> -x c++ -c 2>&1 \
>>> +// RUN: | FileCheck -check-prefix=CHK-RTTI %s
>>> +
>>> +// CHK-RTTI: clang{{.*}}" "-triple" "nvptx64-nvidia-cuda"
>>> +// CHK-RTTI-SAME: "-fno-rtti"
>>> +
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at lists.llvm.org
>>> <mailto:cfe-commits at lists.llvm.org>
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>>
>>> --
>>> --Artem Belevich
>>
>>
>>
>> --
>> --Artem Belevich
>
>
>
> --
> --Artem Belevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200115/c394a057/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200115/c394a057/attachment-0001.sig>
More information about the cfe-commits
mailing list