[fpc-devel] Policy on reserving error numbers

[J. Gareth Moreton]

Hi everyone,

So I've run into a slight annoyance while developing support for pure 
functions.  The compiler will need new parser messages because of 
situations such as specifying the 'pure' directive when something in 
said function makes it not eligible (a warning). However, whenever a new 
error such as "parser_e_enumeration_out_of_range" is included, it 
ultimately causes a conflict in my branch and I have to shift all my 
numbers forward one.  Not a problem, just a little annoying, and I worry 
that when the patch is finally ready, it might take a while to be 
reviewed and, during that time, a new message is added and causes 
another clash.  Is there a policy on reserving a set of numbers for my 
work so I can rest assured they won't be overwritten? (I've made all of 
the messages that I *think* I will need).


Gareth aka. Kit


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

[J. Gareth Moreton]

Hi everyone,

How is everyone doing?  Sorry for my silence - been a bit tied up with 
things in life.  Anyway, that aside, has there been any further progress 
on reviewing the x86_64 optimizer overhaul over at 
https://bugs.freepascal.org/view.php?id=34628? I ask because I've 
sort-of blocked myself in any further improvements to the peephole 
optimizer.


The other one that requires further review is the node semantic pass 
work over at https://bugs.freepascal.org/view.php?id=35857 - I figure 
there could be some improvements I could make, especially in regards to 
efficiency, but it would be easier to do with the applied patch rather 
than from scratch.  Also, some future optimisations might benefit from 
further analysis of node structures.  For example, if the Free Pascal 
Compiler is to build a project supporting AVX and FMA, it would be 
easier to convert vectored addition and multiplication routines into a 
single fused multiply-add instruction at the node level instead of in 
the peephole optimizer - true, it would still be possible to do it at 
this stage (and it might still have to in order to catch every possible 
case), but there's a risk that the vector is broken up into individual 
scalars before it reaches the peephole optimizer. In particular, I'm 
looking at units like "uComplex" that would greatly benefit from this, 
since the 'complex' data type is generally stored as two sequential 
double-precision floating-point values, this exactly filling a single 
XMM register where operations like addition and subtraction are 
component-wise (also, the operations as defined in the unit are inlined, 
so theoretically can collapse into a single (V)ADDPD instruction).


I'm still working on 'pure' functions on the side, so this is not a lost 
cause!


Gareth aka. Kit


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel