[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <89788DD3-8CD7-43E4-B469-BBBA02B41F42@gmail.com>
Date: Thu, 2 Jul 2015 15:52:58 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: extend SIMD intrinsics
Hi,
I'm thinking about how to gracefully add AltiVec intrinsics into the existing code. Currently pseudo_intrinsics.h makes a good base for incorporating x86 intrinsics, but yet I think it has some problems that may hinder its extendability.
First, as for the existing x86 intrinsics, it's not clear which intrinsics are supported by all platforms. As the width of Intel's SIMD instructions advances, some instructions are deprecated while some new ones are added. If someone implements a new format and wants to use pseudo-intrinsics, he has to check each section of pseudo_intrinsics.h to make sure a specific intrinsic is available on his target platform. I think it would better if we provide a minimum supported set, that is the set of intrinsics supported by ALL platforms. Usually this set contains the mostly used operations, and should meet most demands. If someone want to do further optimization, he could then dig into the comprehensive list of intrinsics supported by a platform, and choose what he needs.
Second, the interfaces exposed by pseudo_intrinsics.h are width agnostic, but not platform agnostic enough. Currently they are too tightly bound to Intel's intrinsics set. Some of them are inconvenient or inefficient to implement with Power/ARM's native intrinsics. OTOH, this may not be a big issue, if non-x86 platforms are not our major concerns.
Those are some thoughts of mine.
Lei
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
