Some people requested a Patreon post as to my plans for 2022 with FPC, so I was happy to oblige.  Plans may change a bit though depending on what happens in life and also what Florian's own vision is with the compiler, but this is the gist of it:

https://www.patreon.com/posts/60922821

Gareth aka. Kit

On Sun, Jan 9, 2022 at 9:09 AM J. Gareth Moreton via fpc-devel <

An interesting read Gareth.thank you for sharing.

It would be really nice to have such roadmaps (or at least visions) from everyone working on the compiler/rtl/packages, and also the roadmap from the core team for the future plans for FPC. This is obviously more than just a trivial amount of work, and there is no guarantee that all the fringe contributors will suddenly harmonize with the core team's vision, but I hope it will generate a slightly more concerted effort to move the project forward.

Christo

One thing we should think about: the current optimizations being added get more and more rare so they are often not tested anymore by the existing regression tests. So maybe we should think about a dedicated facility for assembler optimization testing.

It's probably a good idea, yes.  Normally the optimisations I implement are due to me spotting something in the RTL or compiler disassembly while optimising something else, so the tests per se are in those units.  Dedicated tests, like my recently added POPCNT tests, are a good idea even if the set-up is quite uncommon (e.g. it's rare that one would check, say, PopCnt(X) = 0 (or 0) because checking X directly gives you the exact same result - in that particular case, I added it because it was as simple as adding a couple of labels to a case block.

How should we start with making these tests?

Gareth aka. Kit

The other slight difficulty is that because I'm looking at the direct assembly langauge, I'm not always sure what Pascal code produces said assembly language.  Granted that's because I tend to dump the assembly files without the -al option, and I only tend to use the -ar option if there's some kind of register tracking problem.

Gareth aka. Kit

On Jan 9, 2022, at 2:09 PM, J. Gareth Moreton via fpc-devel wrote: https://www.patreon.com/posts/60922821

Your plans are vectorization are an important gain for linear algebra and games.

Could you detect things like:

var
  a, b, c: TVec2;
begin
  c := a + b * V2(10, 10);

where the vec2 type has operator overloads for common operations? This kind of thing is very common in graphics math and I bet there's some clever ways you could compress that operation down. Curious how the C++ compilers do this also...

Regards,
Ryan Joseph

I have a passion for games programming so this one really rings close for me.  The tricky thing is that early SSE and AVX instructions have to fill and use the entire register - it's only AVX512 that starts to allow partial filling, so things like packed 3-dimensional vectors are a little difficult to manage.  One can't just add a dummy 4th component because then storage won't behave as expected.

Gareth aka. Kit

In regards to vectorisation, one of my first targets is the uComplex unit, which uses a record type consisting of 2 Doubles to hold a complex number and whose operator procedures are good candidates for the 'vectorcall' calling convention under Win64 (it's a little more flexible at creating vectors than Microsoft Visual C++ is).  I'll have to double-check how good the System V ABI is for x86_64-linux when it comes to that.

It will be interesting to see how well this unit can be vectorised under AArch64 as well, since I'm not sure if its calling conventions can be adapted or if we have to make a new one.

Gareth aka. Kit