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 <kenn...@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... :) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
