c

The C language converts to ASM in a very straight forward way. It is ridiculous
to optimize subexprressions and similar stupid things when a competent C
programmer can do it by hand.

Don't make the compiler a clusterfuck because of retard-programmers.

>>1
agreed. gcc is more than 7 million lines of code in the name of optimization

>>1
Somebody hasn't read enough compiler output. Writing good code with a hard limit on live variables is a pain in the ass.

Somebody hasn't read enough compiler output. Writing good code with a hard cock in the anus is a pain in the ass.

C is not low level enough to give that kind of control - and the reason for that is portability.

C compiler should optimize well so that the programmer doesn't have to write in assemble.

Intensive C optimization is a good example of something done at the wrong level.

Premature optimization is the root of all premature optimization.

Recursion is the root of all recursion is the root of all recursion is the root of all recursion is the root of all recursion is the root of all recursion is the root of all recursion is the root of all recursion is the root of all recursion is the StackOverflowError

>>3
The Cudder can do better than any compiler!

>>10
I thought the Cudder was all talk and no action?

The C language converts to ASM in a very straight forward way.

Where's the bit rotate operator? Where's the SIMD?

In order for C compilers to use something as simple as a bit rotate instruction, they have to reverse-engineer your code.

Bit scan is a single instruction on a lot of architectures, but C compilers make you write a loop and have code to turn that loop into a single instruction.

Some languages make your code simpler but need a more complicated compiler. Some languages have a simple compiler but make you write more complicated code.

C is total garbage. C makes the compiler and your code more complicated.

>>12
A C compiler does not *need* to use every available instruction. The C operators represent what all instruction sets are expected to have in common. The whole *point* of C is portability, and your code wouldn't be portable if it depends on instructions specific to a given architecture.

dubs kek'em

>>13

It doesn't need to indeed. But especially for CISC instruction sets, the performance will be complete garbage. With a simple RISC, you can get away with it.

Anyway, any modern compiler should use the LLVM framework as backend. So this is a non problem these days. It can vectorize loops for you, recognize if you are doing a bitscan or whatever. But the problem here is that they use a pattern matching approach. They match an expression to a pattern and then apply a transform if applicable. Patterns are powerful, but it is not possible to always recognize translatable units.

Therefore most compilers have many optimizing steps and repeat certain steps multiple times to make the expressions as simple as possible.

The obvious solution here for the programmer would be: Write simple code, don't micro optimize yourself or you fuck up the pattern matching. If you want to optimize, optimize algorithms instead.

Examine lib/Transforms/Scalar/LoopIdiomRecognize.cpp. It does exactly that: Classify loops to their applications.

It indeed doesn't make sense to not include a bitscan into the language, because if a processor does not have a single instruction for bitscan the compiler can translate it to a efficient implementation for you.

Also if you write your own language, LLVM is your friend. The framework is really easy to extend with new Transforms.

>>15
This is all retarded. Why does the compiler have to have code to recognize a loop with x &= x - 1; when the user wants the number of 1 bits in a word? That's not even a readable idiom for the user unless they already know it.
http://lemire.me/blog/2016/05/23/the-surprising-cleverness-of-modern-compilers/

People think C is Haskell. Haskell was designed for smart compilers with powerful optimizations just to catch up with a normal garbage-collected language. C was designed for the dumbest of the dumb compilers, but it needs sophisticated compilers in order to take advantage of instructions that have been around for 50 years. Rotate isn't rocket science.

That kind of complexity is fine for a language like Haskell, but it's just terrible for a so-called systems language that's supposed to be close to the hardware.

>>16
the portable assembler! let's you use all kinds of CISC instructions from portable C code, and if the target doesn't have it you just produce a few more instructions.

it's actualy not that ridiculous if you think about it in the larger context of compilation: The way a C compiler does instruction selection is by attempting to tile the AST with prepared the instructions it knows matches AST patterns. So exactly the same technique to know when to use an add, mul, or a complicated address calculation is also used to turn that pattern of code into a popcnt inst.

>>16 Nope, doesn't: gcc -Ofast -march=native -mtune=native -S popcnt.c //its a haswell pentium with hardware popcnt
.file "popcnt.c"
.section .text.unlikely,"x"
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl count
.def count; .scl 2; .type 32; .endef
.seh_proc count
count:
.seh_endprologue
xorl %eax, %eax
testq %rcx, %rcx
je .L4
.p2align 4,,10
.L3:
leaq -1(%rcx), %rdx
addl $1, %eax
andq %rdx, %rcx
jne .L3
ret
.L4:
ret
.seh_endproc
.section .text.unlikely,"x"
.LCOLDE0:
.text
.LHOTE0:
.ident "GCC: (tdm64-1) 5.1.0"

GCC 6.1.0 Mingw:
.file "popcnt.c"
.text
.p2align 4,,15
.globl count
.def count; .scl 2; .type 32; .endef
.seh_proc count
count:
.seh_endprologue
xorl %eax, %eax
testq %rcx, %rcx
je .L4
.p2align 4,,10
.L3:
leaq -1(%rcx), %rdx
addl $1, %eax
andq %rdx, %rcx
jne .L3
ret
.L4:
ret
.seh_endproc
.ident "GCC: (GNU) 6.1.0"

#include <stdint.h>
int popcount_builtin(uint64_t x){return __builtin_popcountll (x);}
int count(uint64_t x) {
int v = 0; while(x != 0) { x &= x - 1; v++; } return v;}
//result:gcc -Ofast -march=native -mtune=native -S popcnt.c

.file "popcnt.c"
.text
.p2align 4,,15
.globl popcount_builtin
.def popcount_builtin; .scl 2; .type 32; .endef
.seh_proc popcount_builtin
popcount_builtin:
.seh_endprologue
xorl %eax, %eax
popcntq %rcx, %rax
ret
.seh_endproc
.p2align 4,,15
.globl count
.def count; .scl 2; .type 32; .endef
.seh_proc count
count:
.seh_endprologue
xorl %eax, %eax
testq %rcx, %rcx
je .L5
.p2align 4,,10
.L4:
leaq -1(%rcx), %rdx
addl $1, %eax
andq %rdx, %rcx
jne .L4
ret
.L5:
ret
.seh_endproc
.ident "GCC: (GNU) 6.1.0"

>>13

The C operators represent what all instruction sets are expected to have in common. The whole *point* of C is portability, and your code wouldn't be portable if it depends on instructions specific to a given architecture.

Why does C have multiply? Some CPUs don't have that. C should make you write a loop with addition and have magic code that turns your loop into multiplication. Why does C have bit shifts? Why not make you calculate that x<<3 means x*8 and then multiply or divide (using a loop)?

C shouldn't have floating point either because a lot of CPUs don't support it. C compilers should have magic reverse-engineering technology that turns software floating point algorithms into floating point instructions.

>>17

The way a C compiler does instruction selection is by attempting to tile the AST with prepared the instructions it knows matches AST patterns.

That's how C compilers do it now. C compilers used to be dumb. Most of these new optimizations only exist because they can't be written in C directly.

check em

>>22
Nice.

>>23
Stop impersonating me!

>>24

Stop impregnating me!

>>21
What CPU doesn't have multiply? What's the purpose of writing C software on a CPU that doesn't even have multiply?

>>26
A lot of old and some newer 8-bitters (e.g. small Atmels). But then again, these platforms usually don't have C compilers, either.

>>24
le pedophile sage

>>27
A lot of ARM cores too. (RISCfag stupidity.)

C and C++, the crimes of humanity - Xah Lee

>>30
Who are you quoting?

>>29
What are you talking about? "ARM architecture" does not refer to a single chip.

>>32
Check'em

>>32
"core" here is a term ARM uses for its ABIs, not really related to CPU cores.

>>31
Xah Lee

Check em

>>35
Did Xah Lee also say `` - Xah Lee'' at the end of his sentence? I guess that he must be a really annoying individual if so.

good, there are no more pedophile sagers in this thread. heh.

>>37
Yes.

Pedophile 'who ru qoting'

>>39
fucking pedophile sager.

>>41
Tripcodes are the mark of a pedo!

>>1
A lot of C code is being autogenerated, even if with macros and templates, so it makes sense to optimize it.

>>43
Agreed but you should check my post number