[llvm-dev] Naming clash: -DCLS=n and CLS in code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
While building llvm & clang & libs by giving some optimization options
to the building compiler, the following error happened:

I think it is related to the passed -DCLS=64, because in file
clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411 an enum member
has the same name (CLS), so it does a macro-substitution with the passed value
of CLS, ie. with 64, but which of course then breakes the syntax...

I think such "reserved" names like CLS that can be passed to the compiler(s),
should be avoided as identifiers for naming variables, constants, enum
members, macros etc.


[2845/3381] Building CXX object
tools/clang/lib/Tooling/CMakeFiles/clangTooling.dir/Execution.cpp.o
FAILED: /usr/local/gcc-latest/bin/g++-latest  -DEXPENSIVE_CHECKS -D_DEBUG
-D_GLIBCXX_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Itools/clang/lib/Frontend/Rewrite
-I/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite
-I/sw/src/clang_llvm_dev/clang/include -Itools/clang/include -Iinclude
-I/sw/src/clang_llvm_dev/llvm_trunk/include -fopt-info -pipe -Wall -Wextra
-Ofast                -DCLS=64 -fPIC -floop-nest-optimize --param
simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2       -mrecip=all
          -funroll-loops -fdelete-null-pointer-checks --param
prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations
-Wno-error=unused-parameter -Wno-error=type-limits -fPIC
-fvisibility-inlines-hidden -Werror=date-time -std=c++1y -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -Wno-maybe-uninitialized
-Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections
-fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing
-pedantic -Wno-long-long -O3    -UNDEBUG -MD -MT
tools/clang/lib/Frontend/Rewrite/CMakeFiles/clangRewriteFrontend.dir/RewriteModernObjC.cpp.o
-MF
tools/clang/lib/Frontend/Rewrite/CMakeFiles/clangRewriteFrontend.dir/RewriteModernObjC.cpp.o.d
-o
tools/clang/lib/Frontend/Rewrite/CMakeFiles/clangRewriteFrontend.dir/RewriteModernObjC.cpp.o
-c /sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp
<command-line>: error: expected identifier before numeric constant
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411:3: note:
in expansion of macro 'CLS'
    CLS = 0x0,
    ^~~
<command-line>: error: expected '}' before numeric constant
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411:3: note:
in expansion of macro 'CLS'
    CLS = 0x0,
    ^~~
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6410:20:
note: to match this '{'
  enum MetaDataDlags {
                     ^
<command-line>: error: expected unqualified-id before numeric constant
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411:3: note:
in expansion of macro 'CLS'
    CLS = 0x0,
    ^~~
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6421:1: error:
expected declaration before '}' token
  };
  ^
In file included from
/sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/STLExtras.h:21,
                  from
/sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/StringRef.h:13,
                  from
/sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/StringMap.h:17,
                  from
/sw/src/clang_llvm_dev/llvm_trunk/include/llvm/Support/Host.h:17,
                  from
/sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/Hashing.h:49,
                  from
/sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/ArrayRef.h:13,
                  from
/sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/APFloat.h:21,
                  from
/sw/src/clang_llvm_dev/clang/include/clang/AST/APValue.h:18,
                  from /sw/src/clang_llvm_dev/clang/include/clang/AST/Decl.h:17,
                  from
/sw/src/clang_llvm_dev/clang/include/clang/AST/ASTTypeTraits.h:20,
                  from
/sw/src/clang_llvm_dev/clang/include/clang/AST/ASTContext.h:18,
                  from /sw/src/clang_llvm_dev/clang/include/clang/AST/AST.h:18,
                  from
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:15:
...
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
On Tue, 19 Jun 2018 at 18:22, U.Mutlu via llvm-dev
<[hidden email]> wrote:
> I think such "reserved" names like CLS that can be passed to the compiler(s),
> should be avoided as identifiers for naming variables, constants, enum
> members, macros etc.

Why are you passing that argument in the first place? The compiler
completely ignores it.

I sort of assume some library makes use of it, but if so that library
is certainly not required while compiling Clang and is actually
obscure enough that it's not even obvious from Googling. So it's a bit
of a stretch to claim the token is reserved.

Cheers.

Tim.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
Tim Northover via llvm-dev wrote on 06/19/2018 07:55 PM:
> On Tue, 19 Jun 2018 at 18:22, U.Mutlu via llvm-dev
> <[hidden email]> wrote:
>> I think such "reserved" names like CLS that can be passed to the compiler(s),
>> should be avoided as identifiers for naming variables, constants, enum
>> members, macros etc.
>
> 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.

> I sort of assume some library makes use of it, but if so that library
> is certainly not required while compiling Clang and is actually
> obscure enough that it's not even obvious from Googling. So it's a bit
> of a stretch to claim the token is reserved.

Yes, it might not be required for the Average Joe user, but that's not me :-)
Let me wish you a Good Morning!...  :-)


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
> > 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.

Cheers.

Tim.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
On Tue, 19 Jun 2018 at 20:12, U.Mutlu <[hidden email]> wrote:
> You can find more examples by searching for "DCLS getconf LEVEL1_DCACHE_LINESIZE".

Frankly, it all looks like cargo-cult optimization flagomancy. I'd
suggest you drop it, it's not magical I promise.

Tim.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
Tim Northover via llvm-dev wrote on 06/19/2018 09:22 PM:
> On Tue, 19 Jun 2018 at 20:12, U.Mutlu <[hidden email]> wrote:
>> You can find more examples by searching for "DCLS getconf LEVEL1_DCACHE_LINESIZE".
>
> Frankly, it all looks like cargo-cult optimization flagomancy. I'd
> suggest you drop it, it's not magical I promise.

Hey, I'm working on optimization, and I know "it works".

Curious, have you ever heard of "false sharing" and "true sharing"
and what lies behind them?
Hint: it has todo with the cacheline and its size, and memory alignment etc...

No need to start a sideline discussion here.

Ciao

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
If you're trying to add new functionality, why not do it like

gcc -DLEVEL1_DCACHE_LINESIZE=$(getconf LEVEL1_DCACHE_LINESIZE)

More obvious and much less chance of clashing with something else.

The preprocessor is a very blunt hammer, doesn't know C++, doesn't respect any kind of scope rules. Avoid potential clashes.


On Tue, Jun 19, 2018 at 12:33 PM, U.Mutlu via llvm-dev <[hidden email]> wrote:
Tim Northover via llvm-dev wrote on 06/19/2018 09:22 PM:
On Tue, 19 Jun 2018 at 20:12, U.Mutlu <[hidden email]> wrote:
You can find more examples by searching for "DCLS getconf LEVEL1_DCACHE_LINESIZE".

Frankly, it all looks like cargo-cult optimization flagomancy. I'd
suggest you drop it, it's not magical I promise.

Hey, I'm working on optimization, and I know "it works".

Curious, have you ever heard of "false sharing" and "true sharing"
and what lies behind them?
Hint: it has todo with the cacheline and its size, and memory alignment etc...

No need to start a sideline discussion here.

Ciao


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
In reply to this post by Robin Eklind via llvm-dev
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*.


On Tue, Jun 19, 2018 at 12:12 PM, U.Mutlu via llvm-dev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
On Tue, 19 Jun 2018 at 20:46, Bruce Hoult <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
I'm prepared to give the benefit of the doubt and assume there's a "#ifndef #define ..." somewhere, not shown for brevity.


On Tue, Jun 19, 2018 at 12:49 PM, Tim Northover <[hidden email]> wrote:
On Tue, 19 Jun 2018 at 20:46, Bruce Hoult <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
In reply to this post by Robin Eklind via llvm-dev
Tim Northover via llvm-dev wrote on 06/19/2018 09:49 PM:
> On Tue, 19 Jun 2018 at 20:46, Bruce Hoult <[hidden email]> 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.

We have a famous saying here over in Germany:
"Wenn man keine Ahnung hat, sollte man besser die Schnauze halten."

Enjoy :-)


>> On Tue, Jun 19, 2018 at 12:12 PM, U.Mutlu via llvm-dev <[hidden email]> 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
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
You've just insulted one of the most knowledgeable and helpful people in LLVM land. (no not me) Good luck here in future.


On Tue, Jun 19, 2018 at 1:14 PM, U.Mutlu via llvm-dev <[hidden email]> wrote:
Tim Northover via llvm-dev wrote on 06/19/2018 09:49 PM:
On Tue, 19 Jun 2018 at 20:46, Bruce Hoult <[hidden email]> 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.

We have a famous saying here over in Germany:
"Wenn man keine Ahnung hat, sollte man besser die Schnauze halten."

Enjoy :-)



On Tue, Jun 19, 2018 at 12:12 PM, U.Mutlu via llvm-dev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
In reply to this post by Robin Eklind via llvm-dev
Bruce Hoult via llvm-dev wrote on 06/19/2018 09:46 PM:
> 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 doesn't matter.
The goal is to build an optimized (ie. fast) optimizing compiler.


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
In reply to this post by Robin Eklind via llvm-dev
Bruce Hoult via llvm-dev wrote on 06/19/2018 10:18 PM:
> You've just insulted one of the most knowledgeable and helpful people in LLVM
> land. (no not me) Good luck here in future.

It was he himself with his ignorance and unqualifed replies.


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
In reply to this post by Robin Eklind via llvm-dev
Bruce Hoult via llvm-dev wrote on 06/19/2018 09:41 PM:
> If you're trying to add new functionality, why not do it like
>
> gcc -DLEVEL1_DCACHE_LINESIZE=$(getconf LEVEL1_DCACHE_LINESIZE)
>
> More obvious and much less chance of clashing with something else.
>
> The preprocessor is a very blunt hammer, doesn't know C++, doesn't respect any
> kind of scope rules. Avoid potential clashes.

Yeah, but the problem still would persist. Guess why?... :-)


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code

Robin Eklind via llvm-dev
In reply to this post by Robin Eklind via llvm-dev
> -----Original Message-----
> From: llvm-dev [mailto:[hidden email]] On Behalf Of
> U.Mutlu via llvm-dev
> Sent: Tuesday, June 19, 2018 3:12 PM
> To: Tim Northover
> Cc: LLVM Developers Mailing List
> Subject: Re: [llvm-dev] Naming clash: -DCLS=n and CLS in code
>
> 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".

Right, but there is nothing inherently significant about the symbol
name CLS.  They could have called it MY_SILLY_PARAMETER and it would
have worked equally well.  gcc attaches no special significance to
that name.  Clang attaches no special significance to that name.

Changing the value of CLS works for the software in the article because
that software is written to make use of a symbol named CLS.  That's all.
--paulr

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev