Re: [fpc-devel] LLVM

2016-12-14 Thread Jonas Maebe
Michael Schnell wrote:
> I remember that some time ago an LLVM version of fpc was under discussion.
> 
> I'd like to know the state.

If you don't perform control-flow-based LLVM optimizations, almost
everything works on Darwin/x86-64 (and Linux/x86-64, except for safecall
-- the reason for this extra is that safecall is simply ignored on
Darwin). There are currently about 40 testsuite failures left on
Darwin/x86-64 with LLVM, compared to 26 without LLVM.

With such optimizations enabled, everything apart from try/except and
try/finally should work:
* "should" because I did not actually test this, given that exceptions
are pretty common and hence it's not possible to get a baseline
* it's a pretty big "apart from", obviously. I have some ideas on how to
fix this without breaking compatibility with code produced by the
regular code generators, but I'm still working on it.

Note that even once I fix this, exceptions still won't work equally well
as with our regular code generators, due to the points mentioned under
point 3 of "Progress" at http://wiki.freepascal.org/LLVM

> Background: I might be interested in doing a project that runs in the
> browser. It seems that the upcoming technology for this is WebAssembly.
> I found that an LLVM backend for WebAssembly somewhere is under
> construction.

You would also have to write a WebAssembly RTL for FPC, and you would
have to add some FPC code generator support for a WebAssembly target
(see the first FAQ on the wiki page mentioned above). LLVM IR is by
construction architecture- and platform-specific. It's not like Java
bytecode or CIL (or, for that matter, WebAssembly).


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


[fpc-devel] LLVM

2016-12-14 Thread Michael Schnell

I remember that some time ago an LLVM version of fpc was under discussion.

I'd like to know the state.

Background: I might be interested in doing a project that runs in the 
browser. It seems that the upcoming technology for this is WebAssembly. 
I found that an LLVM backend for WebAssembly somewhere is under 
construction.


Of course another (better) option would be a fpc directly creating 
WebAssembly, but I understand that this will take a lot of time.


Thanks,
-Michael

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


Re: [fpc-devel] RTTI module and "IsManaged" critical problem

2016-12-14 Thread Sven Barth
On 14.12.2016 13:09, Maciej Izak wrote:
> 
> 2016-12-14 11:17 GMT+01:00 Sven Barth  >:
> 
> It should be a Pointer of course, not a PPointer... I will correct
> that later on (I shouldn't commit code that late -.- ).
> 
> So I will wait again ^^

I found the "problem": write_rtti_ref() will always write an indirect
reference (which is by design), so I adjusted the code that it will
really write a direct one. Bye, bye, one level of indirection ;)

Regards,
Sven

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


Re: [fpc-devel] RTTI module and "IsManaged" critical problem

2016-12-14 Thread Sven Barth
Am 14.12.2016 13:09 schrieb "Maciej Izak" :
>
>
> 2016-12-14 11:17 GMT+01:00 Sven Barth :
>>
>> It should be a Pointer of course, not a PPointer... I will correct that
later on (I shouldn't commit code that late -.- ).
>
> So I will wait again ^^

Oh and should you manage to reproduce the problem you mentioned, please
notify me.

>>
>> PPU version is only increased if the structure of the PPU file is
changed. That RTTI change has nothing to do with the PPU.
>
> Yes, that is true, but I want to be sure :) , at the end we have change
in critical place.

The PPU version is only to ensure that the compiler doesn't read the wrong
data when reading a PPU due to added contents.

For the development version it's always the user's responsibility to ensure
that she doesn't mix compiled units from different trunk revisions.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] RTTI module and "IsManaged" critical problem

2016-12-14 Thread Maciej Izak
2016-12-14 11:17 GMT+01:00 Sven Barth :

> It should be a Pointer of course, not a PPointer... I will correct that
> later on (I shouldn't commit code that late -.- ).
>
> So I will wait again ^^

> PPU version is only increased if the structure of the PPU file is changed.
> That RTTI change has nothing to do with the PPU.
>
Yes, that is true, but I want to be sure :) , at the end we have change in
critical place.

This change is big step forward in right direction.

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] RTTI module and "IsManaged" critical problem

2016-12-14 Thread Sven Barth
Am 14.12.2016 10:00 schrieb "Maciej Izak" :
>
> 2016-12-14 0:16 GMT+01:00 Sven Barth :
>>
>> At least the patch as is (with PPointer) didn't trigger anything on
Win64...
>
>  Will it stay as PPointer (PPRecInitTable)? I am wondering why we have
bug (or expected behavior?) for this.

It should be a Pointer of course, not a PPointer... I will correct that
later on (I shouldn't commit code that late -.- ).

>>
>> Committed with a few adjustments. Now I only need to update User Changes
Trunk, but I'll do that tomorrow *yawns*
>
> Thanks... Now I need to merge "few adjustments" into NewPascal -,-'

:P

> Shall we increase CurrentPPUVersion or we will wait some time (we have
many changes pending so probably inc for CurrentPPUVersion has not much
sense yet)?

PPU version is only increased if the structure of the PPU file is changed.
That RTTI change has nothing to do with the PPU.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] RTTI module and "IsManaged" critical problem

2016-12-14 Thread Maciej Izak
2016-12-14 0:16 GMT+01:00 Sven Barth :

> At least the patch as is (with PPointer) didn't trigger anything on
> Win64...
>
>  Will it stay as PPointer (PPRecInitTable)? I am wondering why we have
bug (or expected behavior?) for this.

> Committed with a few adjustments. Now I only need to update User Changes
> Trunk, but I'll do that tomorrow *yawns*
>
Thanks... Now I need to merge "few adjustments" into NewPascal -,-'

Shall we increase CurrentPPUVersion or we will wait some time (we have many
changes pending so probably inc for CurrentPPUVersion has not much sense
yet)?

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel