On 10/01/18 17:06, Martok wrote:
Afaik there are only two limitations:
* routines containing assembly blocks (including pure assembly routines)
cannot be inlined> * regular procedures that contain assembly blocks will never
use regvars
Somehow I have a feeling that the fix for one would also
Hi,
> variables in the same routine. Unlike in e.g. gcc, there are no
> annotations for assembly routines that they expect certain variables to
> be in memory and/or registers, that the block may touch arbitrary memory
> locations, etc. Hence, the compiler is as conservative as possible.
This t
On 07/01/18 23:24, Martok wrote:
Am 05.01.2018 um 18:03 schrieb Jonas Maebe:
regvars have always been disabled for routines that contain assembler
blocks (on all architectures). Sometimes the compiler temporarily uses
registers for other purposes over a longer period, which is why marking
the us
Am 05.01.2018 um 18:03 schrieb Jonas Maebe:
> regvars have always been disabled for routines that contain assembler
> blocks (on all architectures). Sometimes the compiler temporarily uses
> registers for other purposes over a longer period, which is why marking
> the used registers is still req
On 05/01/18 16:41, Martok wrote:
is it possible that the register allocation on x86_64 is a bit inefficient? No
matter the optimization settings, I can never get FPC to use more than the rax
and rdx registers. Especially $Optimization REGVAR does nothing (not even for
loop variables).
Instead, t
Hi all,
is it possible that the register allocation on x86_64 is a bit inefficient? No
matter the optimization settings, I can never get FPC to use more than the rax
and rdx registers. Especially $Optimization REGVAR does nothing (not even for
loop variables).
Instead, two nested loops are enough
