On 24 December 2013 09:37, Iain Buclaw <ibuc...@gdcproject.org> wrote:
> On 23 December 2013 23:02, Manu <turkey...@gmail.com> wrote: > > On 23 December 2013 22:06, bearophile <bearophileh...@lycos.com> wrote: > >> > >> Iain Buclaw: > >> > >> > >> Did you really think that __simd went through a design phase? :-) > >> > >> I understand. So there is still a problem bigger than __simd. > > > > > > To be fair, I don't think this is as significant as it sounds. I agree, > > __simd had no real design, it was just a convenient implementation for > DMD, > > but isn't that always the case for compiler intrinsics? In most cases, > LLVM > > tries to mirror GCC intrinsics, but there are many significant > distinctions > > between LLVM and GCC's intrinsics, making versions in the code for each > > compiler there too. > > In my experience, there is always versioning issues when making use of > > compiler intrinsics, what's important is that the language is able to > wrap > > them up cleanly and effectively. D currently satisfies this requirement > to > > some extent, but in my experience with std.simd, to get to the 100% > mark, I > > really need __forceinline. I can't really finish std.simd to a > satisfactory > > level without it. > > We have an @attribute("forceinline") for that... :o) > DMD doesn't, which is where it's needed the most >_< Ideally, this needs to be standardised, so compiler-specific intrinsics can be properly wrapped up. And sorry, but some compiler intrinsics for DMD really do just shoot > themselves in the foot. > Perhaps, but I'm able to make do with __simd in this case... at least, if I could wrap it effectively.