By the way, what generates that set of operations? I'm curious because I want to see what's going on in the compiler. You see, "incq" and that "mov, add, mov" set aren't equivalent; anything over $100000000 gets truncated with the set, but not with "incq", although it's not a concern if only the lower 32 bits are used.
If both combinations run at about the same speed, then "incq" is better just on account of code size. Gareth aka. Kit On Wed 12/12/18 14:38 , "Marģers ." margers.ro...@inbox.lv sent: > > > > > > Nice spot with the "incq" command > there. It > wasn't intentional for that to be split into 3 > > commands, but is likely just a side- effect of pass > > 1 not being run twice now... granted, since one of > > my criteria was that the code should not be less > > optimal, I'll see if I can watch out for that one. > > > > Both versions are kinda equivalent in execution > > speed. > > > > > One interesting thing to note though is that the > > read and add work on the 32-bit register, but then > > the full 64-bit register is written. > > > > As local variables are meant to be allocated in > > registers, but procedure has calls to other > > procedures, they are stored "temporarily" on stack > > as 64 bit registers. > > It's not an error or at least not an error for > > program logic in this case. > > > > > > > > # [468] inc(sk); > > > > --trunk --------- > > > > incq 272(%rsp) > > > > > > -- overhaul ------- > > > > movl 272(%rsp),%eax > > > > addl $1,%eax > > > > movq %rax,272(%rsp) > > > > > > did you mean to be so? > > > > > > margers > > > > > > > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
