[swift-dev] SIL proposal: remove multiple results from SILValue

[John McCall]

> On Dec 4, 2015, at 9:51 AM, Erik Eckstein <eeckstein at apple.com> wrote:
>> On Dec 4, 2015, at 9:34 AM, John McCall <rjmccall at apple.com> wrote:
>> 
>>> On Dec 4, 2015, at 9:06 AM, Erik Eckstein <eeckstein at apple.com> wrote:
>>> Hi,
>>> 
>>> currently some instructions, like alloc_stack and alloc_box (I think they are the only ones) return 2 values. For this we have the "result number" in SILValue, e.g. %3#0, %3#1
>>> 
>>> We could represent the same by using a projection instruction, e.g.
>>> 
>>> %3 = alloc_stack $Type  // == the old %3#0
>>> %4 = project_stack %1   // == the old %3#1
>>> 
>>> And actually we already have the project_box instruction.
>>> 
>>> This would simplify SILValues and many places in optimization passes/analysis. Yesterday I spent several hours to debug a problem where in some pass the wrong result number was used.
>>> 
>>> What do you think?
>> 
>> This would mean generating a lot of extra instructions for a lot of very common cases, like alloc_stack.
> 
> A quick grep on the optimized stdlib sil shows that we would need only about 5% more instructions.

I have no idea what that’s supposed to tell us, though, because that’s purely the end result of an optimization pipeline that’s heavily focused on removing alloc_stack, alloc_box, etc.

> About compile time, I'm not sure. On the one hand we will have more instructions, on the other hand we would not have to mask out the ValueDef/ResultNumbers from SILValue every time we use it.

If that’s important (and masking is really cheap, but maybe it’s important), there are other representational differences we could make that would optimize that.  For example, we could split the use lists, so that each result stores its type and use list (meaning that instructions without results don’t need use lists at all).

> IMO this is a reasonable tradeoff for making the SIL simpler.
> 
>> 
>> Was your bug related to the implicit conversion of a SILInstruction* -> SILValue that silently uses result 0?  I’ve been thinking for a while that we should make that conditional on the SILInstruction having exactly one result.
> 
> Some sort of: it was a value.getDef() which should just be the value.

Okay, but that’s what I mean: we should go through and make sure that its generally not possible to accidentally use a SILInstruction with multiple (or zero) results in any position where you really need a specific SILValue.

John.