type variables
Bruce Carneal
bcarneal at gmail.com
Sun Aug 2 14:42:39 UTC 2020
On Sunday, 2 August 2020 at 12:16:32 UTC, Stefan Koch wrote:
> On Sunday, 2 August 2020 at 06:36:44 UTC, Bruce Carneal wrote:
>
>> Earlier LLVM work aimed to speed things up there by reducing
>> the cost of "uniqueing" mutable type representations (turning
>> deep/expensive equality checks in to pointer comparisons IIUC).
>> As a guess, DMD already does this type of thing, separating
>> deeper commonalities from shallower differences (names,
>> attributes, and the like).
>
> No, dmd uses the mangle to compare types,
> as the mangle has to be unique and identical for identical
> types.
Thanks for this peek under the hood. I've read a little of the
sdc code but have not dipped in to dmd yet. Should have done so
before opining as I did.
>
>
>> Looks like many of LLVM's more recent problems stem from C/C++
>> related issues. Again not a problem for DMD.
>>
>> Still, even concrete/lowered type representation is much less
>> a "solved" problem than I imagined if LLVM is anything to go
>> by.
>
> Hmm yes, everyone has their own type representation, as much as
> I like bashing LLVM
> for this they can't be faulted as they try to be a general
> framework.
>
Yes. Reportedly LLVM has had problems with a mutable type
representation that is "uniqueified" after the fact. IIUC, DMD
simplifies this significantly by constraining the evolution of
the internal type representation. That constraint appears to be
so strong, strongly pure IIUC, that unique names could be
provided far upstream of any deep template invocations.
>> The improvements suggested by Manu and Stefan are looking
>> pretty good.
>
> Thanks!
More information about the Digitalmars-d
mailing list