[Mesa-dev] [PATCH v2 05/12] gallium/tgsi: Add new 'has_label' opcode info flag, and fix tgsi_text.c to use it.

[Francisco Jerez]

Jose Fonseca <jfonseca at vmware.com> writes:

> ----- Original Message -----
>> The 'is_branch' TGSI opcode info flag was being interpreted
>> incorrectly by tgsi_text.c as if it implied that the opcode requires
>> a
>> label token -- that's not the case on e.g. IF, BGNLOOP or ENDLOOP.
>
> IF, BGNLOOP or ENDLOOP used to have a label. And some old shaders still use it, e.g., src/gallium/tests/graw/fs-write-z.c:
>
>      " 0: MOV OUT[0], IN[0]\n"    /* front-facing: red */
>       " 1: IF IN[0].xxxx :3\n"
>       " 2:   MOV OUT[1].z, IMM[2].yyyy\n"   /* red: Z = 0.4 */
>       " 3: ELSE :5\n"
>       " 4:   MOV OUT[1].z, IMM[2].xxxx\n"   /* blue: Z = 0.5 */
>       " 5: ENDIF\n"
>       " 6: END\n";
>
> But now, the only opcode that requires label arguments are CAL/CALLNZ I believe.
>
Oh, I had no idea this had been the case before.

>> Add a new opcode info field that marks an opcode as requiring a TGSI
>> label token, and replace the incorrect usage of 'is_branch' with it.
>
> Actually, instead of adding this new has_label, please simply modify tgsi_text to consume a label when the next token ':', or ignore otherwise. That is, make labels optional everywhere.
>
OK, I'll leave this patch out and make the parsing of labels optional in
tgsi_text instead.

> And please make sure that the tests in src/gallium/tests/graw still work
>
> Also, could you please describe what exactly the semantics of is_branch you think are correct?
>
I had the impression it referred to the ability of an instruction to
alter the flow of control.  I.e. an instruction whose predecessor or
successor aren't necessarily the lexical ones.

> Jose
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120326/e6d6c663/attachment.pgp>