Pelles C > Feature requests

Optimizer

(1/3) > >>

John Z:
I just ran across one of my programs that compiles and runs fine under v11 with max speed optimizations and extras checked but compiling the exact same sources under v12 introduces a hidden (for lack of a better term) error where a procedure using GetOpenFileNameW always fails.   If I #pragma optimize(  none  ) just for the specific procedure then it works like V11. So far I've been unable to replicate in a small example....so there must be optimization interactions with other parts of the source code even though un-optimizing  just this procedure 'fixes' it.  Whatever 'it' is is not limited to speed or extras - every optimize setting introduces the problem...

It would be nice to have both more granularity and more (some?) verbosity in what the optimizer changes.  Maybe unreasonable but shouldn't hurt to ask  :)

John Z

frankie:
John try to post the assembler generated in the procedure with and without the optimization, this could help to identify the problem.

John Z:
Good suggestion frankie.

I extracted the 'offending' procedure from the big source module into its own source module.
Stripped almost everything down to the bare minimum 1168 bytes non-optimized object file and
a 1110 bytes optimized object file - much better than the two ~97kb files  :) and the issue is still
exists, thankfully.  In addition the ~58 byte difference is consistent with the difference in the 97kb files,
so the issue is captured.
Attached are the two object files and the basic streamlined & stripped down C procedure to the minimum.

Just thinking maybe another approach would be use V11 with optimization on the same code to compare with V12 optimization....

When the code fails the GetOpenFileNameW(&ofn) function immediately returns false and never even tries to display the open dialogue.  Maybe I should add GetLastError() and see if that clarifies anything...

Appreciate any insights you have,
Thanks
John Z

Update:  GetLastError says everything is fine even though it failed to display the dialogue . . . oh well  :(

John Z:
Well the more I test it the more I think it is not an optimizer issue.
The optimization in v12 is probably exacerbating a hidden memory overflow
issue somewhere in my code that v11 didn't impact.

Anyway I hope you didn't spend too much time on this.

Hopefully I can find the root cause elsewhere . . . .

Thanks,
John Z

frankie:

--- Quote from: John Z on September 17, 2023, 10:52:06 AM ---Well the more I test it the more I think it is not an optimizer issue.
The optimization in v12 is probably exacerbating a hidden memory overflow
issue somewhere in my code that v11 didn't impact.

--- End quote ---
I think the same. Looking at the generated code, see image below, the 2 versions are the same apart from the position of the ofn structure and the filename buffer that are exchanged in memory. Then one version calls the memset function while the other implements the last locally using string instructions.
Last difference is the check of return value of function GetOpenFileNameW, made with a 'cmp eax,0' in the unoptimized case, and with a 'test eax,eax' in the other case (that is a shorter and much more efficient coding).
Better you check the whole code, initializations, allocations (static, auto, dynamic), ecc.  ;)

Navigation

[0] Message Index

[#] Next page