Re: How to fix code blocks?

[Marc Nieper-Wißkirchen]

Thank you for the feedback.  I tested the patch you uploaded today.
It works now.

Marc

Am Di., 3. Jan. 2023 um 12:04 Uhr schrieb Paulo César Pereira de
Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
>
> Hi Marc,
>
> Em seg, 2 de jan de 2023 11:47, Marc Nieper-Wißkirchen 
> <marc.nieper+gnu@gmail.com> escreveu:
> >
> > For purposes of dynamically calling code, I need the following layout
> > of the assembled code:
> >
> > 0x00: 16-byte header
> > 0x10: entry point #1
> > 0x20: entry point #2
> >
> > I want to use the new align/skip instructions for this.  My code
> > generator currently looks like this:
> >
> >         align (16)
> > header:
> >         skip (16)
> > entry1:
> >         jump label1
> >         align (16)
> > entry2:
> >        ...
> > label1:
> >        jump entry2 ; or some other code
> >
> > However, with setup, GNU lightning often "optimizes" the block order
> > so that entry1 is no longer at the correct offset.  How can I reliably
> > prohibit this?  Putting skip (1) after the second align (16) seems to
> > help in my experiments.
>
>   The skip might be working due possibly confusing the optimizer in
> some way that might change in the future. It would be good to have
> an example to fully understand the condition.
>
>   Your code should be already ensuring that the entry is already 16
> bytes aligned.
>   There is no block reordering, but the pattern:
>
> entry1:
>    jmp label1
>    ....
> entry2:
>    ...
> label1:
>    jmp entry2
>
> will be usually changed to:
>
> entry1:
>    jmp entry2
>    ...
> entry2:
>
> due to simple/safe jump threading optimization.
>
>   Arguably this could be also "the" bug breaking your logic. If the
> "..." after "jmp entry2" is either "note", "name" or align it might
> remove the "jmp entry2". I mean arguably because the original idea
> for "align" was just to align labels, and filled with nops.
>
>   Please experiment removing the:
>    case jit_code_align:
> from lib/lightning.c:_redundant_jump()
>
>   I will push a patch for the above case as it clearly could break
> the usage you describe.
>
>   You can also use jit_indirect() to prevent a label from being optimized
> or removed,  or move the address to a register and use jit_jmpr() as a
> way to prevent any optimization. But the logic you are describing must
> be supported.
>
> > Thanks,
> >
> > Marc
>
> Thanks,
> Paulo
>