-
Notifications
You must be signed in to change notification settings - Fork 416
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various fixes #2
Conversation
…able When two functions having local variables with same name, the previous beheviour would result in name clash if these functions were inlined in the same one.
Initialisation information is lost, initialized globals are seen as an variable declaration followed by an assignement. But glsl forbid assignments at global scope, so we need to track them and initialize at the start of the main function.
* unary operators werent parenthesised, which give a nasty bug for inv(x) : a / inv(x) -> a / 1 / x -> a / x ! * x % y does not exists in glsl, it's mod(x, y)
Do you have some shader examples where your changes were needed (parenthesis and the global assignment stuff)? I'd like to add them (or stripped down versions) to the tests. |
for the parenthesis: }For the Global: |
Do you have repro shader for the inlining bug with variable names? |
mmm, could not reproduce, looks like it's not needed anymore thanks to rename_inlined_variable function. |
Great, now I only need to figure out how to apply only the two commits out of this pull request ;) |
I've applied your parenthesis commit, and then applied the global initializers fix manually (also replaced STL vector; rest of code does not use it so probably not worth dragging STL in...) Thanks for the patches! |
You're welcome, thanks. |
- recent gdb handles DWARF fine (tested both with version 7.1.90.20100730 from mingw-w64 project, and 7.5-1 from mingw project) - http://people.freedesktop.org/~jrfonseca/bfdhelp/ was updated to handle DWARF - stabs requires ugly hacks to prevent compilation failures - mixing stabs/dwarf prevents proper backtraces (which is inevitable, given that the MinGW C runtime is pre-built with DWARF) For example, without this change I get: (gdb) bt #0 _wassert (_Message=0xf925060 L"Num < NumOperands && \"Invalid child # of SDNode!\"", _File=0xf60b488 L"llvm/include/llvm/CodeGen/SelectionDAGNodes.h", _Line=534) at ../../../../mingw-w64-crt/misc/wassert.c:51 aras-p#1 0x0368996b in _assert (_Message=0x39d7ee4 "Num < NumOperands && \"Invalid child # of SDNode!\"", _File=0x39d7e94 "llvm/include/llvm/CodeGen/SelectionDAGNodes.h", _Line=534) at ../../../../mingw-w64-crt/misc/wassert.c:44 aras-p#2 0x00000004 in ?? () aras-p#3 0x00000004 in ?? () aras-p#4 0x0f60b488 in ?? () aras-p#5 0x00000000 in ?? () While with this change I get: (gdb) bt #0 _wassert (_Message=0xfb982e8 L"Num < NumOperands && \"Invalid child # of SDNode!\"", _File=0xefbcb40 L"llvm/include/llvm/CodeGen/SelectionDAGNodes.h", _Line=534) at ../../../../mingw-w64-crt/misc/wassert.c:51 aras-p#1 0x039c996b in _assert (_Message=0x3d17f24 "Num < NumOperands && \"Invalid child # of SDNode!\"", _File=0x3d17ed4 "llvm/include/llvm/CodeGen/SelectionDAGNodes.h", _Line=534) at ../../../../mingw-w64-crt/misc/wassert.c:44 aras-p#2 0x033111cc in getOperand (Num=4, this=<optimized out>) at llvm/include/llvm/CodeGen/SelectionDAGNodes.h:534 aras-p#3 getOperand (i=4, this=<optimized out>) at llvm/include/llvm/CodeGen/SelectionDAGNodes.h:779 aras-p#4 llvm::SelectionDAG::getNode (this=0xf00cb08, Opcode=79, DL=..., VT=..., N1=..., N2=...) at llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2859 aras-p#5 0x03377b20 in llvm::SelectionDAGBuilder::visitExtractElement (this=0xfb45028, I=...) at llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:2803 [...] Reviewed-by: Brian Paul <brianp@vmware.com>
Fix code generation when textureProjLod is used.
Hi,
Here are some fixes for the glsl code generator bug I encountered while optimizing our engine glsl code (translated from hlsl with hlsl2glslfork :) ), I did not run the test suite as the test app is not Linux compatible yet, but the results should be changed mainly due to more paranoid parenthesis.
Cheers,
Maxime Coste.
P.S. there looks to be a bug in copy_propagation elements code, I saw
a.xy = a.yx;
a.x = -a.x;
becoming
a.xy = a.yx;
a.x = -a.y;
I'm investigating