[cfe-dev] constexpr bit_cast status?

[Erik Pilkington via cfe-dev]

I think its mostly just for ease of implementation. Looks like LLVM 
already optimizes __bulitin_memcpy -> bitcast, and piggybacking on the 
existing builtin saves us from from having to write custom 
Parse/Sema/IRGen for a new construct. Also, I think we'd 
(hypothetically) have to fallback to IRGenning __builtin_memcpy in 
general since IR bitcast doesn't support IR aggregates, but C++ bit_cast 
does.

On 10/31/18 4:05 PM, JF Bastien wrote:
> It seems simpler to map it directly to the existing IR construct 
> (bitcast) instead of the odd IR memcpy. But 🤷‍♂️
>
> On Oct 31, 2018, at 3:40 PM, Erik Pilkington 
> <erik.pilkington at gmail.com <mailto:erik.pilkington at gmail.com>> wrote:
>
>>
>>
>> On 10/31/18 3:23 PM, Richard Smith via cfe-dev wrote:
>>> On Mon, 29 Oct 2018 at 13:09, JF Bastien via cfe-dev 
>>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>>
>>>     Richard recently made __builtin_memcpy constexpr in some cases:
>>>     https://reviews.llvm.org/rL338941
>>>     His patch currently disallows all type-puns.
>>>
>>>     Erik is looking at implementing a bit_cast intrinsic for clang,
>>>
>>>
>>> Is there a reason to make it a new builtin (which I think is what 
>>> you're suggesting) rather than extending the existing 
>>> __builtin_memcpy support to cover all the bit_cast cases? (Eg, is 
>>> the idea to make it exactly cover the cases that std::bit_cast 
>>> supports?) If we want both, it'd be good to at least make the two 
>>> share code.
>>
>> No real reason I guess, I suppose that approach would lead to a lot 
>> less boilerplate, so it probably makes more sense. I'll have a chance 
>> to really dig into this in a week or two, so hopefully I'll can put a 
>> patch up soon.
>>
>>>     at which point libc++ can use it. ADT won’t be able to do so
>>>     until we migrate to C++20 (and toolchains support it).
>>>
>>>     We also want to reach out to the RedHat maintainers of libstdc++
>>>     to make sure we don’t adopt a weirdly different builtin.
>>>
>>>
>>>
>>>>     On Oct 29, 2018, at 12:56 PM, will wray via cfe-dev
>>>>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>>>
>>>>     std::bit_cast was added to the C++ 20 draft this summer:
>>>>     http://eel.is/c++draft/bit.cast
>>>>
>>>>     In September JFB added a header with implementation (in llvm
>>>>     namespace):
>>>>     llvm/include/llvm/ADT/bit.h
>>>>
>>>>       // This file implements the C++20 <bit> header.
>>>>       ...
>>>>       // - It isn't constexpr because that requires compiler support.
>>>>
>>>>     What compiler support is it waiting on? What's the status?
>>>>
>>>>     _______________________________________________
>>>>     cfe-dev mailing list
>>>>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>     _______________________________________________
>>>     cfe-dev mailing list
>>>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://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/20181031/ed8f15bf/attachment.html>