Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Nov 2005
Offline Last Active Aug 22 2016 01:50 PM

Posts I've Made

In Topic: Unexpectedly horrible optimization. VS2015. x64 target.

22 August 2016 - 01:17 PM



Tried the old code with U3 - same behavior.

Which at this point i am confident enough to call a bug (*) - no compiler should fail at this kind of basics. I have compared both compilations and they are nearly identical (even ends up using the exact same registers with same instructions throughout) - with the sole exception of minor difference at the function call site and the unnecessary spill (non-spilling code just uses R8 [free to trash] instead of RBX [requires spill]) and frame code.


Platform Toolset: Visual Studio 2015 (v140). Is this correct? How can i confirm the new compiler is in use (edit: i did notice that the compiler specifically told it had to recompile all functions instead of doing the usual incremental rebuild)?


Did i miss something?


*) Which it obviously technically is not - since the functional end result is exactly what it should be.

In Topic: Unexpectedly horrible optimization. VS2015. x64 target.

22 August 2016 - 11:26 AM

Not really familiar with ASM, but codegen bugs/shortcomings are not unheard of. Which VS 2015 version BTW? FYI, Update 3 introduced a completely new optimizer which is on by default.


Still on Update1. New optimizer? Did not know that, thanks. Well, then i need to update - will do that.


However, before i revisited the forums today i noticed (since all that code was on slow path i did not care much what happened on that path before) that i can easily convince the compiler to tail-call optimize out the, somehow offending, function call:


----------------- before:

        auto res = man.get(at);
        return res;
----------------- after:

        return man.getAndUnlock(at);

... and the compiler happily obliged - all of the spill nonsense is gone (ebx gone and all the frame junk also gone [since all the function calls got tail-call optimized causing the caller to be essentially leaf function enabling all relevant optimizations]).


So, unfortunately can not tell whether U3 would have made a difference (would be interesting to know, so might un-fix when i update).

In Topic: VS2015 without internet explorer

19 February 2016 - 06:56 AM

I have no need nor intention to "bite the bullet" or whatever. The original problem has been solved as noted in previous post:



However, an update to the question i raised that was not answered:


Reinstalling IE nuked some of the settings needed for Classic Explorer to work (allow third party extensions got unchecked) - so, i needed to get access to the so called "internet" options again. Previously the only way i knew to do that was though IE and had to temporarily install IE just for that. This time i had a bit more luck with searching (by the virtue of Classic Shell having a sensible help around that does not wander through unrelated programs like IE) ... so, ...


... that darn thing is accessible through Settings -> Control Panel -> Internet Options. (yep, sue me, but i did not think of looking around in control panel)


That and the settings mentioned in the linked post are all that is needed to make VS happy. No need to have IE around.

In Topic: VS2015 without internet explorer

18 February 2016 - 03:07 AM

Reporting back.


Installed IE11 and:

* cookies must be allowed.

* whitelisting (trusted sites) did not work (live.com, visualstudio.com, microsoft etc/etc) somewhy. Only thing i found was that at least VS2013 had a bug where the sign in process actually mistakenly checked javascript access against the "internet zone" even though all the sites were in "trusted sites" zone - maybe it has not been fixed with VS2015?

* setting internet zone to high security (basically disabling everything) and specifically allowing javascript (active scripting)

Uninstalled IE (+restart even though it did not ask for it, just to be sure) and its security settings remained intact.


Had no problems registering / signing in after that. Yay!


I'm guessing by uninstalling ie's front end you've removed the javascript engine. After all, javascript is a user side facility not a backend facility ...


The frontend does very little (UI platform etc?) ... AFAIK, anything related to rendering an actual webpage is not considered to be part of it (the whole renderer is a separate embeddable component that is made basically inseparable from rest of the OS).


Comments from more knowledgeable dudes'n'dudettes welcome.

In Topic: VS2015 without internet explorer

18 February 2016 - 01:11 AM


Suppose i get to register it somehow - will it keep working without internet explorer?


It does require an occasional re-checkin, so you might have issues.



:/ ... that would be a nuisance (especially if it really is as often as mentioned [1-2 months]). So, register-time temporary fix is a no-go ... whatever i do, it will have to always work.

IE has been gradually built into the OS with only the front end being made uninstallable (to get around the lawsuit while still maximizing interdependency). The constant crap avalanche IE presence caused via updates was why i got rid of it way beck when - now only the OS internal parts get updates.


Checked with Wireshark and the "sign in" makes some https traffic with distinctly MS related payloads/destinations to fly around - so, it seems to be able to use the built in part of IE just fine, but just lacks the rights to run Javascript as the message indicated.


I wonder if installing IE to add some whitelists and then immediately uninstalling IE will perma-fix the situation :/ Can i do that without installing IE? How?


Will try it out when i get the time and say how it goes.