llvm dev - Oct 2015 - SRET consistency between declaration and call site

Hello,
while debugging assertions when building libm for 32bit Sparc, I hit the
following IR:

  complex_mul_libcall:
    call void @__muldc3({ double, double }* sret %tmp, double %conv, double
0.000000e+00, double %a.real, double %a.imag) #2

  ...

  declare void @__muldc3({ double, double }*, double, double, double, double)

The same IR is essentially generated for i386 too, so it is not Sparc
specific. Unlike i386, Sparc has an assertion in its codegen that the
function called must have the sret attribute on corresponding argument.

The question is now: is the Sparc assertion correct? If yes, this
inconsistency should be checked in the IR verifier, IMO.

Joerg

Hi Joerg,

On 3 October 2015 at 02:29, Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> while debugging assertions when building libm for 32bit Sparc, I hit the
> following IR:
>
>   complex_mul_libcall:
>     call void @__muldc3({ double, double }* sret %tmp, double %conv, double
0.000000e+00, double %a.real, double %a.imag) #2
>
>   ...
>
>   declare void @__muldc3({ double, double }*, double, double, double,
double)
>
> The same IR is essentially generated for i386 too, so it is not Sparc
> specific. Unlike i386, Sparc has an assertion in its codegen that the
> function called must have the sret attribute on corresponding argument.
I think we should view this as a special case of bitcasting functions
to different types (not quite types because it turns out function
attributes aren't part of the type in IR, but morally the same thing).
LLVM allows those casts normally.

It's more difficult to justify for actually declared globals (rather
than random pointers), but I'm still reluctant to ban it outright.

Tim.

On Sat, Oct 03, 2015 at 08:43:49AM -0700, Tim Northover
wrote:
> Hi Joerg,
> 
> On 3 October 2015 at 02:29, Joerg Sonnenberger via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > while debugging assertions when building libm for 32bit Sparc, I hit
the
> > following IR:
> >
> >   complex_mul_libcall:
> >     call void @__muldc3({ double, double }* sret %tmp, double %conv,
double 0.000000e+00, double %a.real, double %a.imag) #2
> >
> >   ...
> >
> >   declare void @__muldc3({ double, double }*, double, double, double,
double)
> >
> > The same IR is essentially generated for i386 too, so it is not Sparc
> > specific. Unlike i386, Sparc has an assertion in its codegen that the
> > function called must have the sret attribute on corresponding
argument.
> 
> I think we should view this as a special case of bitcasting functions
> to different types (not quite types because it turns out function
> attributes aren't part of the type in IR, but morally the same thing).
> LLVM allows those casts normally.
Well, we do consider it an ABI changing attribute for the purpose of
tail call (under "musttail") and we are loosing the dereferencable
information. Removing the assert is easy, I just want to make sure there
is consensus it is the right thing to do.

Joerg