[Issue 6658] Slow short array equality

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=6658



--- Comment #9 from Iain Buclaw <ibuclaw at ubuntu.com> 2013-04-02 02:45:00 PDT ---
(In reply to comment #8)
> DMD: https://github.com/D-Programming-Language/dmd/blob/v2.062/src/e2ir.c#L2431
> 
> GDC: https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-elem.cc#L100
> 
> LDC: https://github.com/ldc-developers/ldc/blob/master/gen/arrays.cpp#L812
> 
> It's all reimplementations of the same thing. I guess there was a reason for
> why the layer of abstraction was chosen to be this high, but in this situation
> it's not doing anyone any favors.
> 

When David first released gdc, the (In reply to comment #6)
> (In reply to comment #5)
> > I'd just like to say that statement is false.  It wasn't a patch in the
> > frontend, and no one but DMD benefits.
> 
> Really??
> 
> We're talking about this, right?
> https://github.com/D-Programming-Language/dmd/commit/c984175cf25dfa17b3956e8e33ff83547fa56b0a
> 
> I thought GDC/LDC simply provided their own implementation of el_* and the elem
> type.

When gdc was first released, it provided it's own implementation of dt* and the
dt_t type.  This is now what I widely regard of as a bad move.  The DMD
implementation of toobj.c; todt.c; typinf.c; has been getting further from
GDC's copy of that part of the frontend, thus has become a pain to maintain
upon each frontend update.  Frankly I can never see it working trying to hack
and wrap dmd backend calls into producing something that another backend see's
as correct.  So I'll be yanking those three files out of dfrontend/ sometime
around this fall too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------