[fpc-devel] x86_64 Optimizer Overhaul

[J. Gareth Moreton]

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.roked at 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
> 
> 
> 
> 
> 
> 
>