Evaluate constexpr functions when possible

[LADSoft]

constexpr functions could sometimes be evaluated at compile time to result in a constant value.

[chuggafan]

So, I've looked at GCC and clang in semi-depth and I've figured out that GCC is SIGNIFICANTLY more condensed in where the source code for evaluating constexpr is, issue is, gcc also is significantly harder to follow (because GCC does this c in c++ hybrid thing that only utilizes an old version of c++), https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/constexpr.c seems to be the main area of constexpr evaluation, and for clang it seems to be literally all over the place so much so I have trouble figuring out if there's any main area for it.

(note: this was about the constexpr-evaluation in general rather than just making it compile-time)

[LADSoft]

the 'constant optimizer' was originally written to optimize subexpressions, I only later turned it into something that would reduce an entire expression to a constant. So yes it is probably a little more involved than it needs to be...

[LADSoft]

this is a roadblock for the libcxx tests so i moved it into the current milestone.

[LADSoft]

this is coming along pretty well. Mostly functional, still need to clean some things up with literal classes though.... basically need to make them 'real' if something outside the constexpr functionality needs to either use the class instance or modify a class member... took about a 4% hit on compile time though (for a file compiling in 1 sec anyway with vectors and maps) so I may have to try to optimize the code a little better...

[LADSoft]

I got the compiler to compile itself again. I have a couple of bug fixes to the constexpr handling that I have to work out though...

[LADSoft]

this is done from a functional standpoint; leaving it open while we see if it needs speed optimizations...

[chuggafan]

Has the atomics tests been re-run? I know a few of those have failed per some of the old changes due to some of the structures having constexpr constructors.

[LADSoft]

not the libcxx ones. I'll try that out in a minute...

[LADSoft]

1 failure. Will get on it soon...

[LADSoft]

i did fix the failure... over the weekend I also found the constexpr stuff needed to support returning simple structures that had been initialized with a constexpr constructor. I'm mostly through developing that but there are a couple of minor bugs yet...

[chuggafan]

Sounds really good! I hope we can find some hard things that use a lot of constexpr evaluations so that we can do profiling on a single file to determine hotspots after this is done, as I feel that constexpr will be one of the largest features that can slow down the compile times.

[LADSoft]

yeah constexpr could conceivably slow down compile times if we had a file that used it heavily.... i ended up making a mini-interpreter for the high level statement/expression trees... the main things I've been testing with are all the variations on std::min, std::max, std::minmax and some things with pairs out of the libcxx tests, plus I wrote a couple of tests of my own... I'm wrapping all those tests in a single file that will get run as part of the compiler tests during the build 😄

[GitMensch]

What is the state of this issue?

[LADSoft]

it still needs a little work lol... I was thinking about picking myself up and trying to finish it this week....

[LADSoft]

I've been working on this... slowly... almost there...

[LADSoft]

got this to a happy place. Whenever the appveyor builds are copacetic we'll have a release...

[chuggafan]

Woot! I'll probably be trying to break this in half and measure the constexpr performance sometime in december, at least so that there's a good look into bottlenecks because I know a huge amount of compilation elsewhere is the dual-punch of templates and constexpr.

[LADSoft]

well it was a little buggy... better now though lol...