[cfe-commits] r165273 - in /cfe/trunk: lib/CodeGen/CodeGenFunction.cpp test/CodeGen/catch-undef-behavior.c test/CodeGenCXX/catch-undef-behavior.cpp test/CodeGenCXX/return.cpp

[David Blaikie]

On Wed, Jan 23, 2013 at 10:27 AM, Daniel Dunbar <daniel at zuster.org> wrote:
>
>
>
> On Tue, Jan 22, 2013 at 5:55 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>>
>> On Tue, Jan 22, 2013 at 5:42 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
>> wrote:
>>>
>>> On Jan 22, 2013, at 5:23 PM, Chandler Carruth <chandlerc at google.com>
>>> wrote:
>>>
>>> On Tue, Jan 22, 2013 at 4:15 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>>>>
>>>> Hi Richard,
>>>>
>>>> I object pretty strongly to using unreachable here for C++ code bases.
>>>
>>>
>>> There was some discussion surrounding this, and I'm still pretty strongly
>>> in favor of it...
>>>
>>>
>>> IMHO you still haven't given enough justification; your proposed
>>> optimization opportunity in
>>> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/025326.html is
>>> specific to a full covered switch, which can be handled with an optimization
>>> that targets this case.
>>
>>
>> It is applicable to any circumstance where there is a programmer-known
>> invariant that all paths terminate in a return which is not statically
>> determinable. I've seen both predicated code with if/else chains of this
>> form, and switches.
>
>
> The right way to handle this is with appropriate annotations. This is simply
> not a good argument for emitting unreachable.

The only reason LLVM/Clang have all those unreachables annotating the
end of functions is because of simplistic GCC warning. For codebases
that build Clang only it seems quite likely that those would not be
present. I don't really see how "users should be annotating these
things" is sufficient - users get all sorts of other optimizations
that the language allows without having to be explicit about that.

>
>> But I actually think we're approaching this from the wrong direction. The
>> C++ standard is extremely clear that this is UB. Given that, I think we
>> should aggressively tell users about this problem with their code. If the
>> optimization benefits aren't worthwhile, then I would argue for emitting
>> llvm.trap in *all* cases rather than just in non-optimized builds. While I
>> think the optimization benefits are both easy to get and worth it, I don't
>> have a collection of benchmarks that rely on it so I'm not going to fight
>> tooth and nail for it. I just don't understand sacrificing it when we don't
>> have to.
>
>
> I'd much prefer llvm.trap in all cases instead of unreachable, although I
> still don't see much value in forcing users to fix code that from their
> perspective "works".
>
>  - Daniel
>
>>
>>
>> However, if you're arguing that Clang should define the behavior of
>> falling off the end of a function in C++ as an extension, I think that
>> requires significant evidence of the problems this causes and following the
>> usual Clang policies a move toward defining the behavior in the standard. I
>> think the biggest problem with that is going to be coming up with a useful,
>> rational description of what this defined behavior is in the C++ language.
>> There are many differences between C++ and C here that (IMO) make it very
>> challenging to specify.
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>