Should work now. There's a weird quirk with certain kinds of references
that get implicitly converted into immediates (constants) by the
assembler, but since CMOV doesn't support immediates, they remain
references and cause different code to be generated. x86_64-linux
passes on my computer
In the meantime, here's the new CMOV improvements. This is another big
one for the peephole optimizer on x86, although largely confined to just
a few methods:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/198
Gareth aka. Kit
--
This email has been checked for viruses by
That answers that. MOV/CMP/CMOV is faster than CMP/CMOV/CMOV. Thanks.
I've been finalising another peephole optimisation. What started as a
means to permit constants in CMOV instructions using a bit of trickery
became almost an entire rewrite of the optimisation if only because I
was
> Am 16.04.2022 um 12:31 schrieb Thorsten Otto via fpc-devel
> :
>
> On Samstag, 16. April 2022 06:49:07 CEST J. Gareth Moreton via fpc-devel
> wrote:
> > but I haven't been able to find an authoritive
> > source on this yet.
>
> Did you check what for example GCC generates for similar C
On Samstag, 16. April 2022 06:49:07 CEST J. Gareth Moreton via fpc-devel
wrote:
> but I haven't been able to find an authoritive
> source on this yet.
Did you check what for example GCC generates for similar C constructs? I don't
think it uses cmov at all.
> Am 16.04.2022 um 06:49 schrieb J. Gareth Moreton via fpc-devel
> :
>
> Hi everyone,
>
> In the x86_64 assembly dumps, I frequently come across combinations such as
> the following:
>
> cmpl%ebx,%edx
> cmovll%ebx,%eax
> cmovnll%edx,%eax
>
> This is essentially the
