| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove the other places that set LinkStatus to false since they all
immediately follow a call to linker_error. The function linker_error
was previously known as linker_error_printf. The name was changed
because it may seem surprising that a printf function will set an
error flag.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GLSL spec says:
"If a built-in function is redeclared in a shader (i.e., a
prototype is visible) before a call to it, then the linker will
only attempt to resolve that call within the set of shaders that
are linked with it."
This patch enforces this behavior. When a function call is processed
a flag is set in the ir_call to indicate whether the previously seen
prototype is the built-in or not. At link time a call will only bind
to an instance of a function that matches the "want built-in" setting
in the ir_call.
This has the odd side effect that first call to abs() in the shader
below will call the built-in and the second will not:
float foo(float x) { return abs(x); }
float abs(float x) { return -x; }
float bar(float x) { return abs(x); }
This seems insane, but it matches what the spec says.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31744
|
| |
|
|
|
|
| |
Fixes piglit test glsl-function-chain16 and bugzilla #34203.
NOTE: This is a candidate for stable release branches.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Update the max_array_access of a global as functions that use that
global are pulled into the linked shader.
Fixes piglit test glsl-fs-implicit-array-size-01 and bugzilla #33219.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
| |
|
|
| |
These are already picked up by ir.h or glsl_types.h.
|
| | |
|
| |
|
|
|
|
|
| |
Fixes piglit test glsl-override-builtin. The linker incorrectly found
the prototype for the float signature, rather than adding a new
prototype with the int return type. This caused ir_calls with type int
to have their callees set to the float signature, triggering an assert.
|
| |
|
|
| |
Make glsl include only main/core.h from core mesa.
|
| |
|
|
|
|
|
| |
In most cases, we needed to be reparenting the cloned IR to a
different context (for example, to the linked shader instead of the
unlinked shader), or optimization before the reparent would cause
memory usage of the original object to grow and grow.
|
| | |
|
| |
|
|
|
|
| |
Otherwise, ir_function_inlining will see the body of the function from
the unlinked version of the shader, which won't have had the lowering
passes done on it or linking's variable remapping.
|
| | |
|
| |
|
|
|
|
|
| |
Instead of using ir_call::callee, search for the signature in the
linked shader. This will allow resolving calls from functions
imported from other shaders. The ir_call::callee pointer in the
imported function will still reference a signature in the original shader.
|
| |
|
|
|
|
| |
The list of shaders to search needs to be provided as an explicit
parameter to support coming changes. At that point there is no reason
for it to be in the class. Also, fix some of the 'const' decorators.
|
|
|
This handles the easy case of linking a function in a different
compilation unit that doesn't call any functions or reference any
global variables.
|
