llvm dev - May 2018 - first class types

Hello,

I see here: https://llvm.org/docs/LangRef.html#ret-instruction

That the return instruction must only return values of first class types,
which would exclude struct and arrays. But some llvm instrinsics do return
struct, and it does not seems to be enforced on any function.

Is that restriction lifted and the documentation not up to date? Can we
return arrays?
I see the same restriction for select. Can/should we lift it too?

-- 
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180524/695b2f26/attachment.html>

On 2018-05-25 00:39, Alexandre Isoard via llvm-dev
wrote:
> Hello,
> 
> I see here: https://llvm.org/docs/LangRef.html#ret-instruction
> 
> That the return instruction must only return values of first class
> types, which would exclude struct and arrays. But some llvm
> instrinsics do return struct, and it does not seems to be enforced on
> any function.
> 
> Is that restriction lifted and the documentation not up to date? Can
> we return arrays?
> I see the same restriction for select. Can/should we lift it too?
In practice, you can return structs and arrays, and this while you stay
within the optimizer, but how targets handle this is very variable.
X86 internally lowers it to sret or something very similar to sret
whereas lesser used targets (think MSP430) may outright assert.

My understanding is that calling an intrinsic that returns a struct
is defined (and never needs a ret instruction), but returning a struct
from user code (which does need a ret instruction) is not, which is
why LangRef is written like that.

-- 
whitequark

Ah, that's why Clang is obsessively pushing them into return by reference?

On Thu, May 24, 2018 at 6:29 PM, whitequark <whitequark at whitequark.org>
wrote:
> On 2018-05-25 00:39, Alexandre Isoard via llvm-dev wrote:
>
>> Hello,
>>
>> I see here: https://llvm.org/docs/LangRef.html#ret-instruction
>>
>> That the return instruction must only return values of first class
>> types, which would exclude struct and arrays. But some llvm
>> instrinsics do return struct, and it does not seems to be enforced on
>> any function.
>>
>> Is that restriction lifted and the documentation not up to date? Can
>> we return arrays?
>> I see the same restriction for select. Can/should we lift it too?
>>
>
> In practice, you can return structs and arrays, and this while you stay
> within the optimizer, but how targets handle this is very variable.
> X86 internally lowers it to sret or something very similar to sret
> whereas lesser used targets (think MSP430) may outright assert.
>
> My understanding is that calling an intrinsic that returns a struct
> is defined (and never needs a ret instruction), but returning a struct
> from user code (which does need a ret instruction) is not, which is
> why LangRef is written like that.
>
> --
> whitequark
>


-- 
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180524/03ea0733/attachment.html>

On 25 May 2018 at 01:39, Alexandre Isoard via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> That the return instruction must only return values of first class types,
> which would exclude struct and arrays. But some llvm instrinsics do return
> struct, and it does not seems to be enforced on any function.
IMO it's the wording that tries to define "first-class" that's
dodgy.
I don't think it's trying to describe the concept of primitive types
(which would exclude structs), but rather to distinguish first-class
from metadata and function types (as distinguished from function
pointer types) that it makes no sense to return, or do much else with.

This fits with the introductory sentence: "Values of these types are
the only ones which can be produced by instructions".

Cheers.

Tim.