CT Information about target CPU and Related cross-compile
Ilya via digitalmars-d-ldc
digitalmars-d-ldc at puremagic.com
Wed Dec 30 12:07:02 PST 2015
On Wednesday, 30 December 2015 at 15:20:35 UTC, Johan Engelen
wrote:
> On Sunday, 27 December 2015 at 23:47:41 UTC, Ilya Yaroshenko
> wrote:
>> On Sunday, 27 December 2015 at 17:34:26 UTC, Johan Engelen
>> wrote:
>>> On Saturday, 26 December 2015 at 20:47:39 UTC, Ilya
>>> Yaroshenko wrote:
>>>
>>>> Can these features be added to LDC?
>>>>
>>>> 1. Basic compile time information about target CPU such as
>>>> L1/L2/L3 cache sizes and available instructions set, e.g.
>>>> SSE2, AVX, AVX2, AVX512.
>>>
>>> Do you have a proposal for a set of function names / version
>>> IDs / ...? This sounds like a simple thing to add.
>>> I'm not sure about cache sizes: is it currently possible to
>>> specify the target microarchitecture on the cmdline?
>>
>> I have found that core.cpuid can provide runtime information
>> about cache sizes, it is enough. However amount of SIMD
>> registers and their sizes should be known at compile time.
>>
>> What do you mean with "set of function names / version IDs"?
>
> (I am pretty new to D, etc.)
> Can you give me a sample of code showing what "API" you expect
> for this stuff?
Dispatching example:
@target("default") //used for ctfe code
int foo () {
// The default version of foo.
return 0;
}
@target("sse4.2")
int foo() {
// foo version for SSE4.2 if compiler is LDC
return 1;
}
@target("arch=atom,+sse2")
int foo() {
// foo version for the Intel ATOM processor with SSE2 suport
return 2;
}
Compile time features example:
version(LDC)
{
enum bool a = __target(has, "avx2");
enum bool b = __target(compatible, "core-avx2");
enum bool c = __target("broadwell");
}
else version(GNU)
{
...
}
>>>> 2. Related cross-compile. For example: target is x86_64; AVX
>>>> support can be checked at runtime using core.cpuid; so I
>>>> want to force LDC to compile three versions of BLAS for SSE,
>>>> AVX and AVX512, and choose better in runtime.
>>>
>>> Something like this?
>>> https://gcc.gnu.org/wiki/FunctionMultiVersioning
>>
>> Yes! Or runtime check at least.
>
> I had been thinking about implementing function multiversioning
> before. It's great that someone wants it :-)
More information about the digitalmars-d-ldc
mailing list