Re: [fpc-devel] vmul commutative optimization?

2019-11-12 Thread J. Gareth Moreton 
The Microsoft ABI is a bit restrictive when it comes to record types; as 
described here 
, 
"Structs and unions of size 8, 16, 32, or 64 bits, and __m64 types, are 
passed as if they were integers of the same size." So unfortunately, a 
single-precision complex number is treated as a 64-bit structure and 
passed as an integer.  The System V ABI, on the other hand, would pass 
the two entries through the lower 64 bits of XMM0.  Vectorcall, 
theoretically, should put the two components into XMM0 and XMM1, because 
the complex type would be considered a "homogeneous vector aggregate" 
(with floats as 1-dimensional vectors).


I think the overhead that comes with issues such as this is the reason 
why vectorcall was developed in the first place.


Gareth aka. Kit

On 12/11/2019 16:05, Marco van de Voort wrote:


Op 12/11/2019 om 16:08 schreef J. Gareth Moreton:
It's true.  With VMULSS, only the first parameter (third parameter 
under Intel notation) can be an address (source: Intel(R) 64 and 
IA-32 Architectures Software Development Manual, Volume 2B, Page 4-154).


I'll see if I can work in that optimisation for the commutative 
operations (+ and *) at some point from the node side.


Thanks.

Another tidbit I noticed while playing with  (elements of) the complex 
patch is that if I set the elementsize to double (re:double;im:double) 
that with vectorcall loads all data into registers.


However if I make it single, (iow the tcomplex is 8-byte), the records 
are loaded into integer registers, and the compiler stores them to the 
stack and then reloads them.


This matters less for me since it won't vectorize anyway (see inline 
and philosophy thread) I'll change this routine to assembler I think, 
accepting a pointer and load and store from that thread.


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

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

Re: [fpc-devel] vmul commutative optimization?

2019-11-12 Thread Marco van de Voort 


Op 12/11/2019 om 16:08 schreef J. Gareth Moreton:
It's true.  With VMULSS, only the first parameter (third parameter 
under Intel notation) can be an address (source: Intel(R) 64 and IA-32 
Architectures Software Development Manual, Volume 2B, Page 4-154).


I'll see if I can work in that optimisation for the commutative 
operations (+ and *) at some point from the node side.


Thanks.

Another tidbit I noticed while playing with  (elements of) the complex 
patch is that if I set the elementsize to double (re:double;im:double) 
that with vectorcall loads all data into registers.


However if I make it single, (iow the tcomplex is 8-byte), the records 
are loaded into integer registers, and the compiler stores them to the 
stack and then reloads them.


This matters less for me since it won't vectorize anyway (see inline and 
philosophy thread) I'll change this routine to assembler I think, 
accepting a pointer and load and store from that thread.


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

Re: [fpc-devel] vmul commutative optimization?

2019-11-12 Thread J. Gareth Moreton 
It's true.  With VMULSS, only the first parameter (third parameter under 
Intel notation) can be an address (source: Intel(R) 64 and IA-32 
Architectures Software Development Manual, Volume 2B, Page 4-154).


I'll see if I can work in that optimisation for the commutative 
operations (+ and *) at some point from the node side.


Gareth aka. Kit


On 12/11/2019 12:22, Marco van de Voort wrote:

I compiled some bits with avx, and noticed that when you do

asingle:=someconstant*othersingle;

then that generates something like

    vmovss    TC_$FFTS_$$_C31(%rip),%xmm2
    vmulss    %xmm0,%xmm2,%xmm0

while if you do

asingle:=othersingle*someconstant;

it generates

    vmulss    TC_$FFTS_$$_C32(%rip),%xmm2,%xmm2


I assume the reason is that only the first param can be an address, 
and the second a register. But the compiler isn't smart enough to 
exchange them.


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


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

[fpc-devel] vmul commutative optimization?

2019-11-12 Thread Marco van de Voort 

I compiled some bits with avx, and noticed that when you do

asingle:=someconstant*othersingle;

then that generates something like

    vmovss    TC_$FFTS_$$_C31(%rip),%xmm2
    vmulss    %xmm0,%xmm2,%xmm0

while if you do

asingle:=othersingle*someconstant;

it generates

    vmulss    TC_$FFTS_$$_C32(%rip),%xmm2,%xmm2


I assume the reason is that only the first param can be an address, and 
the second a register. But the compiler isn't smart enough to exchange them.


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

Re: [fpc-devel] Internal error 2018062911

2019-11-12 Thread J. Gareth Moreton 
No problem. Glad to help.

Gareth aka. Kit

On Tue 12/11/19 08:44 , C Western l@c-m-
w.me.uk sent:
> I can confirm thet the fpc build now 
works for me (and my application 
> 
> works also).
> 
> 
> 
> Thanks for the quick fix
> 
> 
> 
> Colin
> 
> 
> 
> On 12/11/2019 02:22, J. Gareth Moreton 
wrote:
> 
> > All fixed,
> 
> >
> 
> > https://bugs.freepascal.org/view.php?
id=36299
> >
> 
> > Gareth aka. Kit
> 
> >
> 
> > 
__
_
> 
> > fpc-devel maillist  -  fpc-
de...@lists.freepascal.org
> > https://lists.freepascal.org/cgi-
bin/mailman/listinfo/fpc-devel
> 
> 
> 
> 
> 
> 
__
_
> 
> fpc-devel maillist  -  fpc-
de...@lists.freepascal.org
> https://lists.freepascal.org/cgi-
bin/mailman/listinfo/fpc-devel
> 
> 
> 
> 
> 

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

Re: [fpc-devel] Currency bug and FPC 3.2.0

2019-11-12 Thread LacaK 




Then seems that bug reported here 
https://bugs.freepascal.org/view.php?id=33439 and in related reports 
is back again?


I have reported it as a new bug: 
https://bugs.freepascal.org/view.php?id=36176


I'll check the currency stuff the next days, I have still some 
uncommitted patches regarding this lying around.



Just reminder (to Florian) ;-)
(any news on this topic)

L.


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

Re: [fpc-devel] Internal error 2018062911

2019-11-12 Thread C Western 
I can confirm thet the fpc build now works for me (and my application 
works also).


Thanks for the quick fix

Colin

On 12/11/2019 02:22, J. Gareth Moreton wrote:

All fixed,

https://bugs.freepascal.org/view.php?id=36299

Gareth aka. Kit

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



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