[Mesa-dev] [PATCH] gallivm: fix opcode and function nesting

[Zack Rusin]

----- Original Message -----
> Am 28.01.2014 23:08, schrieb Zack Rusin:
> > gallivm soa code supported only a single level of nesting for
> > control flow opcodes (if, switch, loops...) but the d3d10 spec
> > clearly states that those are nested within functions. To support
> > nesting of conditionals inside functions we need to store the
> > nesting data inside function contexts and keep a stack of those.
> > Furthermore we make sure that if nesting for subroutines is deeper
> > than 32 then we simply ignore all subsequent 'call' invocations.
> Hmm I thought nesting worked just fine, except for the fact that when
> using just one stack we'd have needed a much larger one. Wasn't that
> true? (Not arguing about using per-function stacks, just curious.)

The issue is that d3d10 spec is very specific about the nesting requirement being per-subroutine. So just increasing those nesting levels wouldn't really work, because 63 levels in one subroutine and 65 in another doesn't necessarily equal code path that has 64 levels in two subroutines (even both have technically 64 levels) - we get away with it for conditionals but not for function calls.
It's also worth noting that the patch handles overflows which whck explicitly tests for and we were just crashing on those. The overflow behavior is unidentified only for conditionals, subroutine calls above the level 32 /have/ to be ignored (again whck tests for it). 

> > +   ctx->loop_stack[ctx->loop_stack_size].loop_block = ctx->loop_block;
> > +   ctx->loop_stack[ctx->loop_stack_size].cont_mask = mask->cont_mask;
> > +   ctx->loop_stack[ctx->loop_stack_size].break_mask = mask->break_mask;
> I am confused why some assignments use the variables from ctx and some
> from mask here.

The masks are in general global (the 'call' opcode could have been inside switch'es, loops or/and conditionals) so the function contexts push/pop the global masks and need to operate on those. Things that are not masks are in general per-function-context, which means that we can just store them in function contexts.

> As mentioned inline, I don't quite get when the values from mask or ctx
> are used. This might well be correct as this is tricky stuff and the
> diff is difficult to understand.
> Otherwise this looks good to me. Would that also help when we'd switch
> to not always inline all functions?

Yea, I think it would, but then we would need a lot of other changes (storing those masks in some struct inside some global object that each function can reference). But yea, this code isn't the cleanest but function calls, conditionals, loops and switches are inherently difficult in SoA mode so there's not a lot we can do. We need to store the nesting data inside something that resembles function context because d3d is very clear that that's what it wants so everything else we'll be a hack where we just try to imitate that behavior that's going to be uglier than this code.

z