[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:51:51 PST 2020
Ah, you're talking about transferred definitions and code paths
activated because of those definitions? Yes, missed it.
-------------
Best regards,
Alexey Bataev
15.01.2020 1:47 PM, Artem Belevich пишет:
>
>
> On Wed, Jan 15, 2020 at 3:09 PM Alexey Bataev <a.bataev at outlook.com
> <mailto:a.bataev at outlook.com>> wrote:
>
> 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?
>
> You are correct that the NVPTX as the triple is never used for the
> host compilation.
>
> However, I'm talking about host-side *code* as seen by compiler during
> device-side *compilation*. Keep in mind that both host and device
> compilations always see both sides of the source code. The host code
> seen by the compiler during device-side compilation should be allowed
> to use host features that are not available on GPU.
>
> When you RTTI got disabled for NVPTX, it affected *all* code seen by
> the compiler. When GPU-side compiler that targets NVPTX with RTTI
> disabled gets to parse the host function hf()
> (https://godbolt.org/z/Gzsrof) it sees typeid() and complains that
> RTTI is disabled, even though it will never produce any code for hf().
> It should've allowed RTTI use in the host-only code.
>
> --Artem
>
>
>
>
>
> -------------
> 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
>
>
>
> --
> --Artem Belevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200115/d04e732a/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/d04e732a/attachment-0001.sig>
More information about the cfe-commits
mailing list