Re: [fpc-pascal] LLVM Backend Support

2016-09-02 Thread Michael Schnell
On 01.09.2016 03:28, Karoly Balogh (Charlie/SGR) wrote: 90% of the same as for the LLVM backend applies. I suppose inline ASM should be no problem with the GNU compile infrastructure. With the typical "embedded" cross compiling, all high language code is compiled to their ASM dialect and conv

Re: [fpc-pascal] LLVM Backend Support

2016-09-01 Thread Jonas Maebe
On 01/09/16 00:15, African Wild Dog wrote: And about GCC? It supports a wide variety of processors and OS. Apart from what others mentioned, GCC doesn't have a (even semi-)stable interface that can be used by external tools. Someone once started on something like that (https://gcc.gnu.org/wik

Re: [fpc-pascal] LLVM Backend Support

2016-08-31 Thread Sven Barth
Am 01.09.2016 00:15 schrieb "African Wild Dog" : > And about GCC? It supports a wide variety of processors and OS. Why would we want to depend on the behemoth that is GCC as a dependency when FPC currently only needs an assembler and a linker and on some systems not even that? That thought can als

Re: [fpc-pascal] LLVM Backend Support

2016-08-31 Thread Dmitry Boyarintsev
On Wed, Aug 31, 2016 at 6:15 PM, African Wild Dog wrote: > Again,thanks for the detailed explanation. As this is a recurrent > topic,maybe it would be a good ideia to create a wiki page with all these > points. > http://wiki.freepascal.org/LLVM thanks, Dmitry ___

Re: [fpc-pascal] LLVM Backend Support

2016-08-31 Thread Karoly Balogh (Charlie/SGR)
Hi, On Wed, 31 Aug 2016, African Wild Dog wrote: > > The code optimizers, yes. The rest, not so much. > > > >> Will the FPC team, somewhere in the future, adopt the LLVM as the > >> backend on all platforms ? > > > > No, for various reasons: > > Again,thanks for the detailed explanation. As this

Re: [fpc-pascal] LLVM Backend Support

2016-08-31 Thread Karoly Balogh (Charlie/SGR)
Hi, On Wed, 31 Aug 2016, Anthony Walter wrote: > I'm not too familiar with LLVM so I'll ask, is it at all likely that an > LLVM compiler would produce significantly better/faster optimizations > than FPC as it stand currently? What range would be talking about 100% > faster? Less? More? We just

Re: [fpc-pascal] LLVM Backend Support

2016-08-31 Thread African Wild Dog
Em quarta-feira, 31 de agosto de 2016, Jonas Maebe < jonas.ma...@elis.ugent.be> escreveu: > On 31/08/16 05:11, African Wild Dog wrote: >> > The code optimizers, yes. The rest, not so much. > >> Will the FPC team, somewhere in the future, adopt the LLVM as the >> backend on all platforms ? > > No,

Re: [fpc-pascal] LLVM Backend Support

2016-08-31 Thread Jonas Maebe
On 31/08/16 21:47, Anthony Walter wrote: I'm not too familiar with LLVM so I'll ask, is it at all likely that an LLVM compiler would produce significantly better/faster optimizations than FPC as it stand currently? What range would be talking about 100% faster? Less? More? It depends on the kin

Re: [fpc-pascal] LLVM Backend Support

2016-08-31 Thread Anthony Walter
I'm not too familiar with LLVM so I'll ask, is it at all likely that an LLVM compiler would produce significantly better/faster optimizations than FPC as it stand currently? What range would be talking about 100% faster? Less? More? ___ fpc-pascal maillis

Re: [fpc-pascal] LLVM Backend Support

2016-08-30 Thread Jonas Maebe
On 31/08/16 05:11, African Wild Dog wrote: Thanks for the detailed explanation. I asked about it because apparently it is a good idea to adopt the LLVM as the backend for FPC compiler. This would free the FPC's core developers from the task of maintain the backend portion of the compiler, which i

Re: [fpc-pascal] LLVM Backend Support

2016-08-30 Thread Sven Barth
Am 31.08.2016 05:12 schrieb "African Wild Dog" : > > 2016-08-19 4:55 GMT-03:00 Jonas Maebe : >> >> African Wild Dog wrote: >> >> > What is the current status of the LLVM backend support? >> >> "make cycle" works on my machine for Darwin/x86-64, and most test suite >> failures (apart from exception

Re: [fpc-pascal] LLVM Backend Support

2016-08-30 Thread African Wild Dog
2016-08-19 4:55 GMT-03:00 Jonas Maebe : > African Wild Dog wrote: > > > What is the current status of the LLVM backend support? > > "make cycle" works on my machine for Darwin/x86-64, and most test suite > failures (apart from exception handling tests if the optimisation level > is increased, see

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread Jonas Maebe
marcov wrote on Fri, 19 Aug 2016: In our previous episode, Jonas Maebe said: Another, more important, issue is that the LLVM-based compiler also includes the regular code generator for the targeted architecture (to generate entry and exit code for pure assembler routines). FYI, I've been cre

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread Marco van de Voort
In our previous episode, Jonas Maebe said: > Another, more important, issue is that the LLVM-based compiler also > includes the regular code generator for the targeted architecture (to > generate entry and exit code for pure assembler routines). FYI, I've been creating some SSE image conversio

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread Sven Barth
Am 19.08.2016 10:56 schrieb "OBones" : > > Sven Barth wrote: > >> >> Am 19.08.2016 09:55 schrieb "Jonas Maebe" mailto:jonas.ma...@elis.ugent.be>>: >> > As alluded to above, LLVM support needs to be added/tested/maintained >> > separately for each supported architecture and to a lesser extent for >>

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread Sven Barth
Am 19.08.2016 13:24 schrieb "Jonas Maebe" : > > > Jonas Maebe wrote on Fri, 19 Aug 2016: > >> On 19/08/16 10:51, Sven Barth wrote: >>> >>> Why is it that 32-bit targets would be a bit tricky to implement? >> >> >> It's because our code generators don't have full generic support for 32 bit architect

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread Jonas Maebe
Jonas Maebe wrote on Fri, 19 Aug 2016: On 19/08/16 10:51, Sven Barth wrote: Why is it that 32-bit targets would be a bit tricky to implement? It's because our code generators don't have full generic support for 32 bit architectures with 64 bit integer "registers". It's possible to implem

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread Jonas Maebe
On 19/08/16 10:51, Sven Barth wrote: Why is it that 32-bit targets would be a bit tricky to implement? It's because our code generators don't have full generic support for 32 bit architectures with 64 bit integer "registers". It's possible to implement support for something like that (the JVM

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread OBones
Sven Barth wrote: Am 19.08.2016 09:55 schrieb "Jonas Maebe" >: > As alluded to above, LLVM support needs to be added/tested/maintained > separately for each supported architecture and to a lesser extent for > each supported OS. Right now, I only have plans for

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread Sven Barth
Am 19.08.2016 09:55 schrieb "Jonas Maebe" : > As alluded to above, LLVM support needs to be added/tested/maintained > separately for each supported architecture and to a lesser extent for > each supported OS. Right now, I only have plans for x86-64 and AArch64 > (and maybe PowerPC64), on Darwin and

Re: [fpc-pascal] LLVM Backend Support

2016-08-19 Thread Jonas Maebe
African Wild Dog wrote: > What is the current status of the LLVM backend support? "make cycle" works on my machine for Darwin/x86-64, and most test suite failures (apart from exception handling tests if the optimisation level is increased, see point 2 below) are related to LLVM limitations rather

[fpc-pascal] LLVM Backend Support

2016-08-18 Thread African Wild Dog
Hello, What is the current status of the LLVM backend support? Best regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal