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