[llvm-dev] Naming clash: -DCLS=n and CLS in code
Tim Northover via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 19 12:49:33 PDT 2018
On Tue, 19 Jun 2018 at 20:46, Bruce Hoult <brucehoult at sifive.com> wrote:
> Furthermore .. in the articles you reference, the -DCLS=$(getconf LEVEL1_DCACHE_LINESIZE) is passed when compiling the user's program -- one doing extensive blocked matrix operations -- and not when building the *compiler*.
It's worse. At least in the first case, the code looks like it
wouldn't even compile without that definition. That's not an
optimization flag, that's a weird build system.
>
>
> On Tue, Jun 19, 2018 at 12:12 PM, U.Mutlu via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Tim Northover wrote on 06/19/2018 08:54 PM:
>>>>>
>>>>> Why are you passing that argument in the first place? The compiler
>>>>> completely ignores it.
>>>>
>>>>
>>>> CLS stands for cacheline size. It is an important parameter
>>>> for optimization of the generated code, at least with gcc/g++.
>>>> -DCLS=n should have the same importance like for example -DNDEBUG.
>>>
>>>
>>> The GCC source doesn't appear to mention it, and neither does any
>>> documentation I can find. NDEBUG on the other hand is in both the C
>>> and C++ standards.
>>>
>>> I still think there's some weird library out there that interprets it
>>> the way you're suggesting, and Clang is not that weird library.
>>
>>
>> This is from a famous article series titled "What every programmer should know about memory":
>> gcc -DCLS=$(getconf LEVEL1_DCACHE_LINESIZE) ...
>>
>> https://lwn.net/Articles/255364/
>> http://mosermichael.github.io/cstuff/all/blog/2015/12/11/wepskn.html
>> https://www.dcl.hpi.uni-potsdam.de/teaching/numasem/slides/NUMASem_Matrix_multiplication.pdf
>>
>> You can find more examples by searching for "DCLS getconf LEVEL1_DCACHE_LINESIZE".
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
More information about the llvm-dev
mailing list