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