On Fri, Feb 05, 2021 at 02:41:06PM +0200, Wesley Oliver via Std-Proposals wrote:
> Hi,
>
> One other thing that is missing with switch, little combination, which is
> possible and could also be used to improve reduce code is inside the switch
> statement is a before-cases: block, which will run if default case is not
> being executed
> and already know its going to be one of the other cases, then I can add
> section of common code before any cases run, which just logic next step,
> where code could be insert at zero cost, inline of the execution sequence
> .
> So basically before-cases: block
>
> Switch(switchValue, SwitchConstraintModifiersHints) {
> before-cases:, when case 0,1,2 are to be execute this will run, but not for
> the default case.
> case 0:break;
> case 1: break;
> case 2: break;
> default: break;
> }

How do you envision this to be handled?

Should it be an implicit lambda that is run on entry to the cases or should
the code be copied to the beginning of each case.

Also, please note that your suggested syntax is already valid and takes a
chunk out of the users variable space.

constexpr int before = 17;
constexpr int cases = 42;

switch (value) {
before-cases:
case 0: break;
}

This is simple to fix by means of using the label

before-case:

instead.

Another question is if you intend the spelling

before - cases:

to be valid.


> Kind Regards,
>
> Wesley Oliver
>
>
>
> On Fri, Feb 5, 2021 at 2:11 PM Wesley Oliver <wesley.olis_at_[hidden]> wrote:
>
> > Hi,
> >
> > I have been looking to optimize an algorithm execution, with some
> > adaptations and improved logic.
> > One of the things I can across is that I could improve performance by
> > handling a few special end condition cases differently and further again by
> > adding upper bounder range check,
> > The upper bound range check along for default gave me 5-6% performance
> > increase, giving me a total of like 10-14% overall, by combination of a if
> > upper range check and switch.
> > I am sure with this suggested improvement, the compiler will be able to
> > improve this even further with a single compound statement switch
> > statement as I proposed below.
> > So for example:
> > case - 2: at times.
> > case -1: continue/runout/run-on with instructions.
> > case 0: the same thing.
> > for these case just run out.
> > case 1: optimize section of handling .
> > break or goto
> > case 2: optimize section of handling.
> > break or goto
> > case 3: optimize section of handling.
> > break or goto
> > default: complex logic.
> > break or goto
> >
> > What I have found is that since switch typically gets compiled down to if
> > statements or range checks for default. There is a nice optimization here,
> > which I implemented manual, which speeds things save about 5-6% off, but
> > may have room for more assemble optimization.
> > At moment I see sub, he, sub, jne optimization for the switch, but feel
> > could be more if one included the boundaries checking of default in switch
> > statement. As there is still another default boundaries checking of cmp,
> > jle, to the switch.
> >
> > What I would like to propose is SwitchLower and SwitchUpper, which
> > determines,
> > how upper bound can be checked, this saving a bounds check statement and
> > then
> > with this new statement it enforcing a constraint that all case have
> > sequential identifier, no gaps.
> > The code can still be re-ordered for optimization.
> >
> > With knowledge of this, typically translate the switch to a jump
> > switchValue that is already in register that just got ranged checked for
> > the default case, subtract the sequentialOffset, then jump by the
> > switchValue or relative memory offset or instruction offset, depending on
> > instruction set. Then jump one more time to the correct address to continue
> > executing from for that case.
> > Essentially this is a const stack array of positional jump offset encoding
> > directly into the instructions, which should never be exicuted, unless
> > random mistake jump to this data.
> >
> > ASSEMBLE.
> > if(switchValue < Upper | Lower | Both range check)
> > default code
> > else
> > {
> > switchValue -= SequentialOffset;
> > Jump SwitchValue;
> > Jump currentcaseinstructionvalue.
> > }
> >
> >
> > I would like to recommend/propose
> > *switch(SwitchValue, SwitchConstrainsModifierHint) *, where *SwitchConstrainsModifierHint
> > = NoCheck | Both | Upper | Lower | NoDefault | Seqeuenced.*
> >
> > With this additional switchcontrainsModifierHint to a language, the
> > compilers can easily understand range and sequence intention, in unsafe
> > range check type language,
> > which would allow it to further optimize this code much more easily, than
> > a massive crazy analysis of the whole program to determine and ensure these
> > contrains.
> >
> > This simple would allow everyone to communicate there intentional uses of
> > the switch statement, based the large scope of the program they are
> > writing, which would
> > allow for it to further optimize the low level code generation and
> > increase performance.
> >
> > I typically I feel that this would be a minor change, because I am not
> > awhere of an additional parameter that can be supplied to Switch, the
> > SwitchConstraints modified would
> > naturally be backwards compatible with all languages and would be a
> > progressive improvement. The reason for naturally backwards compatible, is
> > that #define could define the sequence false, to be non-op, so in old
> > compilers, SwitchConstraintsModiferHints, would be valid and compile, also
> > due to
> > the fact in C/C++ you can specify multiple commands separated by a comma.
> > switch(switchValue, false) already compiles and the compiler
> > will optimize away the false value I should hope.
> >
> > Compilers can progressively take advantage of the hint and improve the
> > low-level code generation, eventually leading to faster and more precise
> > and consise code
> > being written communicate its range behaviours more clearly.
> >
> > Look forward to hearing what one you guys think.
> >
> > Kind Regards,
> >
> > Wesley Oliver
> >
> > --
> > ----
> > GitHub:https://github.com/wesleyolis
> > LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> > Blog/Website:https://sites.google.com/site/wiprogamming/Home
> > Skype: wezley_oliver
> > MSN messenger: wesley.olis_at_[hidden]
> >
>
>
> --
> ----
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.olis_at_[hidden]

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals