ing a MOV/CMP/CMOV
triplet. In other words, it tries to convert a CMOV to a MOV if it can.
On 16/04/2022 20:03, Florian Klämpfl via fpc-devel wrote:
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
It's funny - for some reason I was expecting a lot of opposition!
I knew about FillChar being written in assembly langauge and know from
experience that FPC will never support the inlining of pure assembler
routines (as Florian said, it will just open a huge can of worms). My
thought was how
It does look like a bug on the surface. What happens if you run the
program with these false negatives? If you get a buffer overrun, then
it is pretty serious.
Gareth aka. Kit
On 16/04/2022 21:35, Wayne Sherman via fpc-devel wrote:
Tested with fpc 3.3.1 trunk (as of 2022-Mar-12) and 3.2.2 s
;7','8','9']); //did not get
expected compile errors or warnings
ShortStringVar8 := CharArrayConst9; //did not get expected compile
errors or warnings
So it looks like the compiler does not treat string compatible types
as strictly as other types and when assigning it c
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 Avas
On 17/04/2022 09:59, Sven Barth via fpc-devel wrote:
But we should have a general mechanism for that, not something that
just handles FillChar.
Regards,
Sven
I do agree - I don't like hard-coded literals like that for handling
special cases.
Gareth aka. Kit
--
This email has been checked
y computer now.
Gareth aka. Kit
On 17/04/2022 08:12, J. Gareth Moreton via fpc-devel wrote:
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
Hi everyone,
I'm having a problem with a certain test failing on my Sliding
Window-based Assembly-level CSE optimisation over at
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/191
Size and speed savings are great and all, but I have one single test
failure on x86_64-linux that
Interesting - I wasn't aware of this intrinsic! I'll make a note of
that one.
It might be useful to transform FillChar calls to the Default intrinsic
at the node level.
Gareth aka. Kit
On 19/04/2022 12:43, Stefan Glienke via fpc-devel wrote:
You are the expert but I am not sure how that ca
nnot see how it could be faster given the initial overhead to produce the
empty temp.
On 19/04/2022 14:49 J. Gareth Moreton via fpc-devel
wrote:
Interesting - I wasn't aware of this intrinsic! I'll make a note of
that one.
It might be useful to transform FillChar calls to the
Hi everyone,
So this is another question on peephole optimisation for x86_64.
Occasionally you get situations where you write a load of constants to
the stack - in this case it's part of an array parameter to a function call:
movl $23199763,32(%rsp)
movl $262149,36(%rsp)
mov
That's a new one... an unknown or unsupported tai_realconst(hp).realtyp
value. Did I break things again?!
Gareth aka. Kit
On 26/04/2022 02:32, Hairy Pixels via fpc-devel wrote:
I’m doing a make all in the RTL and getting this internal error. Can anyone
else replicate this?
/Users/ryanjoseph
time I’ve built from the gitlab
branch on my new M1 Mac and something may be broken in my build system.
On Apr 26, 2022, at 8:42 AM, J. Gareth Moreton via fpc-devel
wrote:
That's a new one... an unknown or unsupported tai_realconst(hp).realtyp value.
Did I break things again?!
Gareth aka.
evel wrote:
On Apr 26, 2022, at 8:58 AM, J. Gareth Moreton via fpc-devel
wrote:
It's just a "make all" in the RTL directory on x86_64-darwin, right? I can
only do x86_64-linux, which I hope is nearly the same, but I'll let you know.
Ok I think this was because I was using
Hi everyone,
My laptop is in the repair shop again unfortunately due to a jammed cooling
fan, so this e-mail may have indentation problems in the mailing list.
That aside, I'm taking the opportunity to look at some optimisations for
AArch64, and in the process I rediscovered the problem with la
Hi everyone,
Building the compiler with -dDEBUG_NODE_XML got broken recently:
C:/lazarus/fpc/3.2.0/bin/x86_64-win64/ppcx64.exe -Ur -Xs -O2 -n
-Fux86_64 -Fusystems
-FuC:/Users/garet/Documents/programming/fpc-opts/rtl/units/x86_64-win64
-Fix86_64 -FEx86_64/bin/x86_64-win64 -FUx86_64/units/x86_6
Hi everyone,
So since a large number of my new optimisations do things at the nodal
level, I need to do much more extensive testing. One thing that was
brought up was testing JVM and LLVM. I've managed to build "ppcjvm" on
x86_64-win64 after downloading the necessary runtimes, but how do I r
The testall.bat file took some modification since it doesn't handle
parameters like testall.sh does. I didn't get too far though:
C:\Users\garet\Documents\programming\fpc-opts\tests\test\jvm>..\..\..\compiler\ppcjvm
-Fu..\..\..\rtl\units\jvm-java -O2 -g test
Generated: .\org\freepascal\test\t
The lack of "javac" is a little confusing. I have a lot to learn!
Gareth aka. Kit
On 08/06/2022 14:15, J. Gareth Moreton via fpc-devel wrote:
The testall.bat file took some modification since it doesn't handle
parameters like testall.sh does. I didn't get too far thou
Okay. got the JDK installed (and got javac), so we're making progress!
Mostly...
testall.sh still won't run since I'm not specifying the correct options
I don't think. I've gotten testall.bat partially working, but still
getting errors (I had to add the '.java' extension to JavaClass to
pre
08/06/2022 16:42, Jonas Maebe via fpc-devel wrote:
On 2022-06-08 15:15, J. Gareth Moreton via fpc-devel wrote:
The testall.bat file took some modification since it doesn't handle
parameters like testall.sh does. I didn't get too far though:
You have to install our own, patched versi
Here it is.
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/237
By the way - thanks for telling me to test my typeconv strip on JVM.
I've got a failure that I need to investigate now.
Gareth aka. Kit
--
This email has been checked for viruses by Avast antivirus software.
http
Hi everyone,
I'm playing around with a peephole optimization (back to my roots!) and
I've come across a relatively simple one that aims to reduce instruction
size occasionally. One part involves reducing the opsize if the
constant is numeric. For example:
testl $17,76(%rcx) -> testb $17
On Montag, 27. Juni 2022 04:43:46 CEST J. Gareth Moreton via fpc-devel
wrote:
> testl $1,%ebx -> testb $1,%bl
Obviously, thats not the same. The latter will only compare the
least-significant byte against 1, and ignore the rest of the register.
The former will also compare the remaind
This was what I was working on:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/252
The same question applies regarding the TEST instruction, but it's a
little more restrictive in this instance in that it's determined that
the program doesn't care about the upper bytes of the reg
That's a litle concerning:
$000100089CA3 OwnerHierarchyName, line 2180 of symdef.pas
Lines 2179 and 2180 of that file are the following:
if assigned(tmp.owner) and
(tmp.owner.symtabletype in
[ObjectSymtable,recordsymtable]) then
Since the access violation doesn
Hi everyone,
Recently I've made some optimisations centred around the SHR instruction
on x86, and there was one pair of instructions that caught my attention:
movl (%rbx),%eax
shrl $24,%eax
Is it permissible to optimise this to (x86 is little-endian):
movzbl 3(%rbx),%eax?
(You could also op
evel wrote:
On 17/08/2022 02:21, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
Recently I've made some optimisations centred around the SHR
instruction on x86, and there was one pair of instructions that
caught my attention:
movl (%rbx),%eax
shrl $24,%eax
Is it permissible to o
Thanks Ondrej.
In the meantime, I've found the problem and am testing a fix. Basically
the function that computes the magic number for a given bit size doesn't
sign-extend it to the full size. In the given example, the signed
divisior +60 for 32-bit produces the multiplicand $8889. Howev
Ah, sorry, that was for #39834 - wrong issue! Disregard.
Gareth aka. Kit
On 18/08/2022 07:28, J. Gareth Moreton via fpc-devel wrote:
Thanks Ondrej.
In the meantime, I've found the problem and am testing a fix.
Basically the function that computes the magic number for a given bit
/Y4v14f9s3
On 17/08/2022 02:21 CEST J. Gareth Moreton via fpc-devel
wrote:
Hi everyone,
Recently I've made some optimisations centred around the SHR instruction
on x86, and there was one pair of instructions that caught my attention:
movl (%rbx),%eax
shrl $24,%eax
Is it permissib
Speaking from experience, db is normally that's the first unit that the
compiler fails to find if there's some kind of configuration problem
(whether with the config file itself or a bug that prevents proper
parsing of it).
Gareth aka. Kit
On 19/08/2022 11:04, Gabor Boros via fpc-devel wrote:
Hi everyone,
So this one has eluded me a little bit... what's the exact difference
between the -Cp and -Op options? I figure it's for specific features on
non-Intel processors, but when building code for AVX2, for example, I
tend to specify "-CpCOREAVX2 -OpCOREAVX2 -CfAVX2". If the code
gen
ssible to actually
do so?
Gareth aka. Kit
On 07/09/2022 19:15, Jonas Maebe via fpc-devel wrote:
On 2022-09-07 16:34, J. Gareth Moreton via fpc-devel wrote:
So this one has eluded me a little bit... what's the exact difference
between the -Cp and -Op options?
-Cp: the code is only gua
Which platform and OS is this for?
Kit
On 28/09/2022 11:53, Gabor Boros via fpc-devel wrote:
Hi All,
With actual FPC (123f196d) and Lazarus (11bb7ce4) got the below error.
Any idea?
sourcefilemanager.pas(311,1) Error: Compilation raised exception
internally
Gabor
Granted I do think the compiler raising an internal exception is rather
unclean... possibly not as bad as in internal error but still something
undesirable.
Kit
On 28/09/2022 18:41, Gabor Boros via fpc-devel wrote:
2022.09.28. 19:09 keltezéssel, Ondrej Pokorny via fpc-devel írta:
That is qu
Hi everyone,
I just made a new cross-platform node-level optimisation -
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/304 - the
subject of which was briefly touched upon in
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/282. This
seeks to remove unnecessary AND
Hi everyone,
I'm looking at more optimisations under x86_64 that use the BMI
instructions. I've come across one situation that I need clarity on...
how are SHL and SHR instructions handled if the shift value exceeds the
word size?
For example, say I have the code "power2 := 1 shl index;"...
On 2022‑10‑24 11:51:32 +0100, J. Gareth Moreton via fpc-devel wrote:
[...] I've come across one situation that I need clarity on... how
are SHL and SHR instructions handled if the shift value exceeds the word
size?
About a half year ago I raised a documentation issue regarding that:
htt
The more I learn!
On 24/10/2022 13:06, Sven Barth wrote:
J. Gareth Moreton via fpc-devel
schrieb am Mo., 24. Okt. 2022, 13:52:
That's useful - thank you. Michael Van Canneyt mentioend he
updated the
documentation for this - where is this usually located? It's no
Thanks Michael. Sven already filled me in - the more I learn!
Kit
On 24/10/2022 16:44, Michael Van Canneyt via fpc-devel wrote:
On Mon, 24 Oct 2022, J. Gareth Moreton via fpc-devel wrote:
That's useful - thank you. Michael Van Canneyt mentioend he updated
the documentation for
What I want to do is the following...
Say I have the expression "(1 shl x) - 1"... under the default AMD
Athlon optimisations, you might get something like this:
(x in %cl, Result in %eax)
movl $1,%eax
shll %cl,%eax
subl $1,%eax
Under -CpCOREAVX2, you might get this (ignoring any zero-extensi
Correction to last post. When applying BZHI to an input ("Result :=
Input and ((1 shl x) - 1)"), the initial "mov $-1,%eax" is unnecessary
unless the mask is being preserved, and is just:
bzhil %ecx,(ref-to-Input),%eax
Kit
On 25/10/2022 13:44, J. Gareth Moreton via fpc-
Hi everyone,
This has been something that has been on my mind for a while now, but
with my increasingly more complex optimisations being developed for the
Free Pascal Compiler and the code becoming an ever bigger spiderweb of
conditions, it got me to start wondering... might compiler optimisat
machine
learning is working the way it is with apparent patterns of emergent
behaviour.
Kit
On 10/11/2022 22:17, Sven Barth wrote:
Am 10.11.2022 um 19:10 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
This has been something that has been on my mind for a while now, but
with my incre
I wouldn't advocate a neural network within FPC since, yes, it would be
unbelievably slow, very difficult to port and even more difficult to
maintain and verify... not just to confirm correct output (e.g. BSR is
good as an approximation to the expression "floor(log2(x))", but it has
some awkwar
mehing I want to try somewhere.
Kit
On 11/11/2022 10:54, Marco van de Voort via fpc-devel wrote:
On 11-11-2022 09:57, Jonas Maebe via fpc-devel wrote:
On 11/11/2022 00:44, J. Gareth Moreton via fpc-devel wrote:
My slight concern is that the x86 peephole optimizer is becoming
pretty bloated
Hi Erik,
If you can send a bug report to FPC's GitLab, that would be ideal, but
if you don't have an account, you're more than welcome to post details
here. All bugs must be squashed!
Kit
On 12/11/2022 13:44, Erik van den Broek via fpc-devel wrote:
Hello, fpc experts.
The beautiful huge f
Hi everyone,
I just need to double-check something. Under CPU16, SizeInt and
SizeUInt are declared as follows:
SizeInt = Integer;
SizeUInt = Word;
Is Integer 16-bit in this case? I always thought Integer was defined as
a signed 32-bit integer under FreePascal. Or is this a bug with
rt
ieb Marco van de Voort via fpc-devel:
On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote:
I just need to double-check something. Under CPU16, SizeInt and
SizeUInt are declared as follows:
SizeInt = Integer;
SizeUInt = Word;
Is Integer 16-bit in this case?
Yes.
Are you sure
evel wrote:
Am 24.11.2022 um 14:15 schrieb Marco van de Voort via fpc-devel:
On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote:
I just need to double-check something. Under CPU16, SizeInt and
SizeUInt are declared as follows:
SizeInt = Integer;
SizeUInt = Word;
Is Integer 16-b
rtl/inc/systemh.inc, line 360
On 24/11/2022 13:52, Michael Van Canneyt via fpc-devel wrote:
On Thu, 24 Nov 2022, J. Gareth Moreton via fpc-devel wrote:
Would it be better to define "SizeInt = SmallInt;" here just so it's
crystal clear what size it is?
Where is &#
Beg your pardon, it's line 451. I was looking at the version of the
file in FPC 3.2.0, not the trunk.
Kit
On 24/11/2022 13:54, J. Gareth Moreton via fpc-devel wrote:
rtl/inc/systemh.inc, line 360
On 24/11/2022 13:52, Michael Van Canneyt via fpc-devel wrote:
On Thu, 24 Nov 2022, J. G
Hi everyone,
I just need to touch on the knowledge base. What tests exist that test
the functionality of rtl/inc/sortbase.pp? As Olly suggested, I'm
looking at creating Introsort for this unit as well, but I need to know
if such a unit already exists or if I need to make my own.
Also, sinc
These are nice but don't actually use the code in rtl/inc/sortbase.pp -
maybe they can be adapted though.
Kit
On 25/11/2022 10:10, Marco Borsari via fpc-devel wrote:
On Thu, 24 Nov 2022 18:51:12 +0000
"J. Gareth Moreton via fpc-devel" wrote:
Hi everyone,
I just need
anything inside of IntroSort there are just swaps
that can go without any reference counting.
On 24/11/2022 19:51 CET J. Gareth Moreton via fpc-devel
wrote:
Hi everyone,
I just need to touch on the knowledge base. What tests exist that test
the functionality of rtl/inc/sortbase.pp? As O
Hi everyone,
I don't know if this is an official term for this, but call it "branch
stitching". It's an idea that came to me recently and which I'm trying
out with some success.
The principle is this... I look for blocks of code that look like the
following (using x86) to start:
jmp .L2
This is something I want to experiment with now. Still waiting on
approval of the TArrayHelper sort merge request though before I start
playing around with reference counts.
Just want to clarify something... if a type is managed, can it be safely
typecast to a pointer in all instances and on
Well that spoils that idea! Is there any way to determine if it's
pointer-based so you can swap references instead of going through the
whole penalty of creating and destroying temporary objects?
Kit
On 28/11/2022 10:07, Sven Barth wrote:
J. Gareth Moreton via fpc-devel
schrieb am Mo
that would be the
https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.GetTypeKind
intrinsic - I could not find that one in the 3.2.0 feature list.
Am 28.11.2022 um 11:17 schrieb J. Gareth Moreton via fpc-devel:
Well that spoils that idea! Is there any way to determine if it&#
On 28/11/2022 12:59, Martin Frb via fpc-devel wrote:
On 28/11/2022 07:22, J. Gareth Moreton via fpc-devel wrote:
...
testb %al,%al
je .Lj733
subb $1,%al
je .Lj734
jmp .Lj732
.balign 16,0x90
.Lj733:
...
jmp .Lj718
.balign 16,0x90
.Lj732
!
Curious to know... at which point did it become favourable to do a
32-byte align rather than a 16-byte align on x86 processors? Should the
compiler start favouring 32-byte aligns for loops, say?
Kit
On 28/11/2022 13:52, Martin Frb via fpc-devel wrote:
On 28/11/2022 14:32, J. Gareth Moreton via fpc
v via fpc-devel wrote:
On 11/24/22 20:51, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
I just need to touch on the knowledge base. What tests exist that
test the functionality of rtl/inc/sortbase.pp? As Olly suggested,
I'm looking at creating Introsort for this unit as well, but
Hmmm, that's a problem! Fair enough.
Kit
On 29/11/2022 09:21, Michael Van Canneyt via fpc-devel wrote:
On Tue, 29 Nov 2022, J. Gareth Moreton via fpc-devel wrote:
Surely that's a bug in the comparison functions that should be fixed
and not something that can be blamed on intros
:
Am 29.11.2022 um 11:08 schrieb Sven Barth via fpc-devel:
J. Gareth Moreton via fpc-devel
schrieb am Di., 29. Nov. 2022, 10:09:
Surely that's a bug in the comparison functions that should
be fixed and
not something that can be blamed on introsort.
kolay Nikolov via fpc-devel:
On 11/24/22 20:51, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
I just need to touch on the knowledge base. What tests exist that
test the functionality of rtl/inc/sortbase.pp? As Olly suggested,
I'm looking at creating Introsort for this unit as well
How so? Heapsort isn't stable either. Is there a variant I'm not aware of?
Kit
On 29/11/2022 16:36, Marco van de Voort via fpc-devel wrote:
On 29-11-2022 17:34, J. Gareth Moreton via fpc-devel wrote:
This is why I hope my own improvement to the version in TArrayHelper
could be us
On 29/11/2022 20:03, Nikolay Nikolov via fpc-devel wrote:
if (a
That's the big one that sorting algorithms rely on... the transitive
law. If that is violated, then you cannot guarantee a sorted result.
It doesn't matter if (a < b) or (b < a) return False for equal elements,
or use (a <=b)
Familarity mostly. More people are familiar with quicksort than
introsort. Are there any explicit code examples where quicksort
succeeds and introsort fails? I'm told even Lazarus crashes (or used to
crash), so I'll be interested to see what code causes (or caused) it.
If the pivot is one o
Any word on testing and approval on the Assembly-level Common
Subexpression Eliminator (using Sliding Window) over at
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/191? I
know there's room for improvement in the future for sure. I just hope
it won't be prone to breaking like th
Hi everyone,
I've made a bit of a breakthrough with the development of pure
functions. I've successfully managed to get the compiler to calculate
the factorial as a pure function in two different forms... one usig a
for-loop, and one using a recursive call (which is where it differs from
'in
it
On 13/12/2022 06:21, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
I've made a bit of a breakthrough with the development of pure
functions. I've successfully managed to get the compiler to calculate
the factorial as a pure function in two different forms... one usig a
for-
So there are bugs in my pure function code, specifically with the use of
current_procinfo - I didn't realise until now that the one relating to
the current function is actually freed after the body has been parsed.
Ideally I would have gone the approach of reusing more of the
pass1_inline code
ch also correctly
replaces the function call with the number 12.
Kit
On 14/12/2022 01:17, J. Gareth Moreton via fpc-devel wrote:
So there are bugs in my pure function code, specifically with the use
of current_procinfo - I didn't realise until now that the one relating
to the current funct
recalculate the output and can just retrieve it.
Kit
On 14/12/2022 10:18, Sven Barth via fpc-devel wrote:
J. Gareth Moreton via fpc-devel
schrieb am Di., 13. Dez. 2022, 22:09:
The next big milestone that I want to achieve is to make this a pure
function:
procedure in
On 14/12/2022 10:18, Sven Barth via fpc-devel wrote:
Wouldn't it make more sense to ensure that the Str() and Val()
intrinsic work correctly inside "pure" functions? After all the
compiler can then simply evaluate the inlinen nodes and does not
have to "interpret" a ton of other
set
to a value the compiler doesn't recognise, it just falls back to regular
call-node handling.
Kit
On 14/12/2022 11:39, J. Gareth Moreton via fpc-devel wrote:
On 14/12/2022 10:18, Sven Barth via fpc-devel wrote:
Wouldn't it make more sense to ensure that the Str() and Val(
to solve.
It might be that I have to find a way to perform purity analysis without
ever calling firstpass on the node tree, which is currently needed for
processing nested pure and inline functions... granted, I can possibly
do that selectively using "foreachnode" or "foreachn
ded. Because only the unoptimised tree
is stored, I felt there was no need to store this twice (doing so would
also increase the size of PPU files).
Kit
On 15/12/2022 21:39, Sven Barth wrote:
Am 14.12.2022 um 12:15 schrieb J. Gareth Moreton via fpc-devel:
To better explain how purity analysi
The purity analysis process is very dependent on the node tree being as
clean as possible, and so depends on a fair few merge requests that have
not yet been approved. I'm guessing Florian and Jonas and others are
somewhat busy, what with being December and all.
- https://gitlab.com/freepasca
ions copy and analyse the same tree. If a
function is both pure and inline, these initial trees will always be
identical, so it is redundant to store two copies.
Kit
On 16/12/2022 06:44, Sven Barth wrote:
Am 16.12.2022 um 02:02 schrieb J. Gareth Moreton via fpc-devel:
The purity analysis p
Happy New Year everybody! Free Pascal lives on!
Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
In my opinion, yes, report this as a bug. Sure, it's what I'd consider
"low priority" since it's just an incorrect informative hint rather than
something critical, but it's a bug nonetheless.
Kit
On 13/01/2023 11:54, Bart via fpc-devel wrote:
Consider the follwoing program:
===
program test;
Hi everyone,
I've just made an update to
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/366, the
request that fixes i40111, removing the band-aid in aoptx86 and
hopefully still fixing the original bug. Can everyone confirm that
i386-linux no longer crashes?
In the meantime I
If HKey is unsigned, then yes, the definition should be
HKEY(DWORD($8001)). I do wonder why Win64 produces that particular
error though because the final destination is an unsigned 64-bit integer.
Kit
On 12/02/2023 17:17, Bart via fpc-devel wrote:
Hi,
This code compiles happily for Win3
Yeah, of course, since LongInt($8001), before typecasting to HKEY,
is specifically a signed constant. So obvious!!
Kit
On 12/02/2023 20:43, Bart via fpc-devel wrote:
On Sun, Feb 12, 2023 at 6:26 PM J. Gareth Moreton via fpc-devel
wrote:
If HKey is unsigned, then yes, the definition
My peephole optimisations mostly save only a handful of cycles each time
which probably won't add up to much for a relatively short test. The
most major optimisation I can think of, although I'm not quite sure when
it was merged, is the method of replacing divisions by a constant with
an equiv
On 01/03/2023 13:11, Martin Frb via fpc-devel wrote:
Hence testing back to 3.2.3 ( unfortunately 3.2.2 has a bug that
matters in this code)
Also, I didn't expect any huge diffs, just wanted to see if anything
can be noted at all. (and if lucky, in that test I run)
I did a test on a more lim
On 01/03/2023 13:10, Sven Barth wrote:
It's a German proverb: "Mühsam ernährt sich das Eichhörnchen"
Regards,
Sven
Thanks Sven!
Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc
Hi everyone,
I need to ask a question about how division nodes are set up (I'm
looking at possible optimisation techniques). I've written the
following procedure:
procedure DoDivMod(N, D: Integer; out Q, R: Integer);
begin
Q := N div D;
R := N mod D;
end;
Fairly simple and to the point.
a realistic case where 95% of your divisors are -1 and you
really need to save those few extra cycles of calling idiv.
On 11/05/2023 11:04 CEST J. Gareth Moreton via fpc-devel
wrote:
Hi everyone,
I need to ask a question about how division nodes are set up (I'm
looking at possible
P.S. I found the code that adds the conditional checks; it's
"doremoveinttypeconvs" in the ncnv unit. However, it's very unclear as
to WHY it's doing it as there's no comments around the code block.
Kit
On 11/05/2023 15:39, J. Gareth Moreton via fpc-devel
then converted elsewhere)
Kit
On 11/05/2023 18:01, J. Gareth Moreton via fpc-devel wrote:
P.S. I found the code that adds the conditional checks; it's
"doremoveinttypeconvs" in the ncnv unit. However, it's very unclear
as to WHY it's doing it as there's no comments aro
Fair enough, but I would like an explanation as to why it's necessary,
because the reason for testing -1 in particular is very unclear, and I
wonder if there's a known misbehaviour with a particular division
function with -1.
Kit
On 11/05/2023 21:27, Wayne Sherman wrote:
On Thu, May 11, 2023
On 11/05/2023 23:04, J. Gareth Moreton via fpc-devel wrote:
Fair enough, but I would like an explanation as to why it's necessary,
because the reason for testing -1 in particular is very unclear, and I
wonder if there's a known misbehaviour with a particular division
function with -1.
before and after this proposed change? And, what min_int is of course
depends on whether targeting a 32-bit or 64-bit system, so best check both
cases.
~Kirinn
On Mon, 15 May 2023 17:21:30 +0100
"J. Gareth Moreton via fpc-devel" wrote:
I made a merge request that removes the comparison
Logically yes, but using 16-bit as an example, min_int is -32,768, and
signed 16-bit integers range from -32,768 to 32,767. So -32,768 ÷ -1 =
32,768, which is out of range. This is where the problem lies.
Internally, negation involves inverting all of the bits and then adding
1 (essentially h
uot; to "-x",
and Intel's NEG instruction doesn't return an error if min_int is its
input operand, but I can't be sure if the same applies to non-Intel
processors and their equivalent instructions).
Kit
On 17/05/2023 09:51, J. Gareth Moreton via fpc-devel wrote:
Logically
ation)
Kit
On 19/05/2023 21:55, Florian Klämpfl via fpc-devel wrote:
Am 19.05.23 um 21:14 schrieb J. Gareth Moreton via fpc-devel:
So I need to ask... should the check for a divisor of -1 still be
performed?
Yes. This is the result of "down sizing" a division. In case of
lon
s a real possibility, should raise an exception if
you try to divide it by -1 since the programmer is asking to downsize
values that could potentially be out of range.
Kit
On 19/05/2023 21:55, Florian Klämpfl via fpc-devel wrote:
Am 19.05.23 um 21:14 schrieb J. Gareth Moreton via fpc-devel:
S
301 - 400 of 473 matches
Mail list logo
