Another bug in continue break handling has appeared.

uint fn() {
  for (;;)
  {
    if (true) break;
    return 0;
  }
  return 1;
}

static assert(fn());

The above code is enough to trigger it.
Apparently the fixup jump for the break is never inserted.
I doubt that this is an off-by-one error again.

It's going to be tricky.

On Saturday, 3 December 2016 at 23:30:58 UTC, Stefan Koch wrote:
> Another bug in continue break handling has appeared.
>
> uint fn() {
>   for (;;)
>   {
>     if (true) break;
>     return 0;
>   }
>   return 1;
> }
>
> static assert(fn());
>
> The above code is enough to trigger it.
> Apparently the fixup jump for the break is never inserted.
> I doubt that this is an off-by-one error again.
>
> It's going to be tricky.

I figured out part of the reason for this bug.
baically it's like this.


> uint fn() {
>   for (;;)
beginBlock:
//causes and unconditonal jump (UC1) after the end of the block
>   {
>     if (true) break;
// causes an unconditional jump(UC2) here to the end of the block
UC2: goto endBlock;
>     return 0;
endBlock:
UC1: goto BeginBlock;
>   }
>   return 1;
> }

On Sunday, 4 December 2016 at 00:14:26 UTC, Stefan Koch wrote:
> On Saturday, 3 December 2016 at 23:30:58 UTC, Stefan Koch wrote:
>> Another bug in continue break handling has appeared.
>>
>> uint fn() {
>>   for (;;)
>>   {
>>     if (true) break;
>>     return 0;
>>   }
>>   return 1;
>> }
>>
>> static assert(fn());
>>
>> The above code is enough to trigger it.
>> Apparently the fixup jump for the break is never inserted.
>> I doubt that this is an off-by-one error again.
>>
>> It's going to be tricky.
>
> I figured out part of the reason for this bug.
> baically it's like this.
>
>
>> uint fn() {
>>   for (;;)
> beginBlock:
> //causes and unconditonal jump (UC1) after the end of the block
>>   {
>>     if (true) break;
> // causes an unconditional jump(UC2) here to the end of the block
> UC2: goto endBlock;
>>     return 0;
> endBlock:
> UC1: goto BeginBlock;
>>   }
>>   return 1;
>> }

This can be fixed by setting a state-flag whenever we are going to process the body of an infinite loop.
If anyone tried at any point to break out of the loop we need to introduce a conditional that becomes false and allows us to exit.
It's ugly but it will work regardless of nesting-level .... I hope.

On Sunday, 4 December 2016 at 00:23:32 UTC, Stefan Koch wrote:
> On Sunday, 4 December 2016 at 00:14:26 UTC, Stefan Koch wrote:
>> On Saturday, 3 December 2016 at 23:30:58 UTC, Stefan Koch wrote:
>>> [...]
>>
>> I figured out part of the reason for this bug.
>> baically it's like this.
>>
>>
>>>   [...]
>> beginBlock:
>> //causes and unconditonal jump (UC1) after the end of the block
>>>     [...]
>> // causes an unconditional jump(UC2) here to the end of the block
>> UC2: goto endBlock;
>>>     [...]
>> endBlock:
>> UC1: goto BeginBlock;
>>> [...]

Some progress had been made on this.
There is still a little hiccup with (true) and (false) conditions but those can be eliminated soon.
For the most part breaking out of infinite loops works now.

I just had a hunch about the continue statement within for-loops being treated incorrectly.

let's see where it leads.

Also the fix for infinite loops has apparently cost us a lot of performance.
I am not sure where this loss is coming from.
Maybe I am just reading my scales wrong ;)

While those codegen remain new features and documentation have reduced priority.

I am doing a screening regarding the structural strength of the architecture.

I would be quite happy to read any thoughts on that matter.

On Sunday, 4 December 2016 at 23:10:34 UTC, Stefan Koch wrote:
> Also the fix for infinite loops has apparently cost us a lot of performance.
> I am not sure where this loss is coming from.
> Maybe I am just reading my scales wrong ;)

it seemed to have t odo with the hardware being particularly busy at the point of measurement.

I fixed a bug in ifStatements. so now all the constant expression trouble should be resolved.

I just improved the handling of void initializations.
Now the code is less pessimistic and will allow them if they are assigned to before use.
However using void variables at ctfe will not result in any performance wins.

On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
> I just improved the handling of void initializations.
> Now the code is less pessimistic and will allow them if they are assigned to before use.
> However using void variables at ctfe will not result in any performance wins.

I found an easily fixable performance problem inside the byte-code generator.
Causing it to allocate 800K per discovery of a new type.
Reducing this will probably make IR generation 10 times faster in the average case.
Clearing 800K takes quite some time.

Furthermore I will revise some design decisions inside the IR generator.
Those are related to how break and continue are handled.
Because continue is still broken.

Hopefully I can fix this without spreading the responsible code around everywhere :)

On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
> I just improved the handling of void initializations.
> Now the code is less pessimistic and will allow them if they are assigned to before use.
> However using void variables at ctfe will not result in any performance wins.

Void initialization are allowed at CTFE ?

On Monday, 5 December 2016 at 07:55:32 UTC, deadalnix wrote:
> On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
>> I just improved the handling of void initializations.
>> Now the code is less pessimistic and will allow them if they are assigned to before use.
>> However using void variables at ctfe will not result in any performance wins.
>
> Void initialization are allowed at CTFE ?

not now, but it looks like needless limitation. any void initialization can be converted to "fill the things with zeroes" in CTFE engine.