Hi,
Implicit function specialization would change that, however that would
mean the generation of a specialized definition each time it is used
in a different unit and for every type.
This calls for a space optimizer that removes unnecessary specializations
3 optimizations could one have:
* If the project already has a specialization with the types in any
unit, then it will not be generated again
* If two different specialization create the same assembly, then the
previous specialization will be reused (bitwise comparison of the code
after it has been generated)
* a semantic analysis that determines whether the specialization is
actually necessary and then does not generate anything new if it is not.
(e.g. if a function is generic <T: TObject>, but no properties of T
are used, but it only cast a result to T (like e.g. a generic
TList.get), then it can create the function for TObject once and then
never again for T. )
Best,
Benito
On 06.09.25 11:47, Sven Barth via fpc-devel wrote:
michael via fpc-devel <fpc-devel@lists.freepascal.org> schrieb am Do.,
4. Sep. 2025, 09:29:
On 2025-09-04 08:55, Hairy Pixels via fpc-devel wrote:
> On Sep 4, 2025 at 1:43:23 PM, michael via fpc-devel
> <fpc-devel@lists.freepascal.org> wrote:
>
>> Personally, I think we already have too much intrinsics to begin
>> with;
>> no matter their behaviour. But that is another discussion
>> entirely...
>
> How so? The reason intrinsics are used is because they can’t be
> replicated at runtime. If you remove them then you lose that
> functionality entirely.
As I wrote, for some it is needed. No arguments there.
But AFAIK many regular functions such as Length(), Inc/Dec() etc. are
also converted to intrinsics.
No doubt for performance reasons, but I'd rather have as little as
possible "compiler magic".
Not performance reasons, but because they need to be usable by many
types and thus can't be expressed using ordinary Pascal in a typesafe way.
Implicit function specialization would change that, however that would
mean the generation of a specialized definition each time it is used
in a different unit and for every type.
Regards,
Sven
_______________________________________________
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
