[llvm-dev] SRET consistency between declaration and call site

[Reid Kleckner via llvm-dev]

On Tue, Oct 6, 2015 at 2:02 PM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, Oct 06, 2015 at 01:33:17PM -0700, Reid Kleckner wrote:
> > You could imagine that __muldc3 might be implemented in C, and it might
> be
> > implemented without using _Complex so that it can be compiled by a
> compiler
> > without _Complex support. Instead of using a _Complex double return type,
> > it would use a pointer outparam as the first parameter, and it would
> return
> > that pointer as usual in RAX. Yes, this is a prototype mismatch and
> > probably UB according to C, but this might be part of an implementation
> > which knows something about the platform lowering.
>
> This argument is really not convincing to me. If you have LLVM IR, you
> are starting from a frontend that should be supporting complex already.
> This really sounds like a case that should be flagged to fix up legacy
> code and not something to silently hide. Does code like this (manually
> turning structure returns into explicit pointers) actually exist? Note
> that the normal way for doing the complex thing is to define a two
> element structure, which would still give the sret.


Basically, LLVM shouldn't assert if Clang produces prototype mismatches,
because they happen in practice. Clang tries really hard to avoid prototype
mismatches. It even has it's own set of assertions in call lowering to
detect them. However, at the end of the day, sometimes it has incomplete
function pointer type information and mismatches happen. An ABI attribute
mismatch is just another type mismatch, but it doesn't require bitcasts, so
it's less obvious.

I mention LTO because that's where most prototype mismatches come up: one
TU saw a complete pointer to parameter type and the other didn't, and now
things look quite different. I'm just saying it happens, and LLVM should
try to be careful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151006/baa9bccd/attachment.html>