[llvm-dev] returning tagged union via registers

[David Chisnall via llvm-dev]

On 8 Oct 2017, at 14:44, Csaba Hruska via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> I'd like to achieve an efficient mapping to x64 machine code. In the ideal case the create function result would be stored only in 2 registers. One i1 for the tag and one i32 for the argument value either come from Con1Data or Con2Data. For storing the i32 values one register would be always enough hence the constructors are mutually exclusive.
> 
> As you can see in the generated code below by default LLVM allocates separate registers for Con1Data and Con2Data arguments (ecx and edx). But ideally it would use only a single register for both. Of course to achieve that the frontend have to prove somehow that these values are on mutually exclusive data flow.

You should probably look at how clang handles unions.  Your example is roughly akin to the following in C:

struct tagged_thing
{
	bool tag;
	union
	{
		int data1;
		int data2;
	};
};

Clang will represent this as:

%struct.tagged_thing = type { i8, %union.anon }
%union.anon = type { i32 }

If you look at how this is passed on x86-64:

struct tagged_thing x()
{
	return (struct tagged_thing){ 1, .data1 = 42 };
}

becomes:

; Function Attrs: noinline nounwind ssp uwtable
define i64 @x() #0 {
  %1 = alloca %struct.tagged_thing, align 4
  %2 = getelementptr inbounds %struct.tagged_thing, %struct.tagged_thing* %1, i32 0, i32 0
  store i8 1, i8* %2, align 4
  %3 = getelementptr inbounds %struct.tagged_thing, %struct.tagged_thing* %1, i32 0, i32 1
  %4 = bitcast %union.anon* %3 to i32*
  store i32 42, i32* %4, align 4
  %5 = bitcast %struct.tagged_thing* %1 to i64*
  %6 = load i64, i64* %5, align 4
  ret i64 %6
}

Which optimises to:

; Function Attrs: norecurse nounwind readnone ssp uwtable
define i64 @x() local_unnamed_addr #0 {
  ret i64 180388626433
}

Clang is coercing the type to an i64, which ensures that it is returned in a single 64-bit register (or, on x86-32, a pair of 32-bit registers).  Unfortunately, the mapping from IR constructs to registers in the back end is in the form of ad-hoc and poorly documented contracts, so you’ll need to compare the output for each version for each target that you care about.

David