[Mesa-dev] [PATCH 2/2] glsl: When linking, emit functions at the tail of the final linked program.

Paul Berry stereotype441 at gmail.com
Mon Aug 8 11:41:12 PDT 2011


On 5 August 2011 18:29, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 08/03/2011 05:07 PM, Paul Berry wrote:
>> When link_functions.cpp adds a new function to the final linked
>> program, it needs to add it after any global variable declarations
>> that the function refers to, otherwise the IR will be invalid (because
>> variable declarations must occur before variable accesses).  The
>> easiest way to do that is to have the linker emit functions to the
>> tail of the final linked program.
>>
>> The linker used to emit functions to the head of the final linked
>> program, in an effort to keep callees sorted before their callers.
>> However, this was not reliable: it didn't work for functions declared
>> or defined in the same compilation unit as main, for diamond-shaped
>> patterns in the call graph, or for some obscure cases involving
>> overloaded functions.  And no code currently relies on this sort
>> order.
>>
>> No Piglit regressions with i965 Ironlake.
>
> Seems reasonable.
>
> Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
>
> That said, I still dislike all this nonsense.  I've really wanted to
> separate these, so a shader contains three separate lists:
>
> 1. A list of global variable declarations (ir_variable *)
> 2. A list of function declarations (ir_function *)
> 3. Global initializer instructions (ir_instruction *)
>
> Then you wouldn't have any of this crap about emitting functions before
> variable declarations, functions in functions, etc, etc.  Plus you
> wouldn't need to dynamically check whether things in your top-level list
> are variables/functions/etc.
>
> Quite some time ago I took a stab at this, but wasn't thinking about
> global initializers, so I made no provisions for them and ended up
> tossing the code.  It'd be nice to resurrect the idea.  If you'd like to
> try, feel free... :)

That's a really good idea.  I'm not sure I have the time to pour into
this right now, but I'll keep it in mind if I have to visit this code
again.


More information about the mesa-dev mailing list