ฝัง
- เผยแพร่เมื่อ 1 ต.ค. 2024
- Compilers are caught in a tug-of-war between increasingly exotic architectures and instruction set extensions on one hand, and our desire for advanced programming languages and PL features on the other. A multi-language, multi-target compiler infrastructure such as LLVM ameliorates the situation somewhat, but engineering fast, effective and correct optimizations for LLVM is challenging. Even after a decade of intense development, there is a long tail of unimplemented optimizations.
University of Utah Associate Professor John Regehr presents Souper, a superoptimizer that gives us a look at some of the optimizations that are missing from LLVM while also avoiding the bugs that are often found in hand-written optimization passes. Souper works by turning LLVM code into queries for an automated theorem prover. When Souper is run on LLVM itself, it identifies thousands of uncaught optimizations and also ranks them according to the likely improvement in code size or code speed that would result from implementing each one.
John Regehr, Associate Professor, School of Computing, University of Utah
12/2/2014
www.cs.washing...
uwtv.org
This lecture is now 6 years old and Clang still can't optimize the example nested if conditions he described.
At least GCC can. (2022 and clang still can't)
Fuck he's gorgeous.
I watched it at x0.75 speed
Martin Jennifer Robinson Jason Martin Michelle
Ok UWTV, do you answer questions or are you just videos? :-)
Right, the lecturer here seems to have a class of students who are all coasting. Why don't they ask any questions? Afraid to be the only one who doesn't understand?
Ok, I have questions:
First off, why declare the function an int? When you're returning the result of a logical query, surely it's more apposite for the return type to be bool? It can then be tested against true and false sensibly. Rather than testing an int for truth, which is illogical captain.
Second, obviously, it Should return 0 if the the compiler is watertight, because whatever the sign, the ints have been declared, 1 and 255. 1 isn't > 255 therefore it's false, 0. If any collision caused due to signage, then the compiler should at least throw a warning? If two's compliment were to reverse the logic and inevitably return an incorrect result based on the logic of the source text, right?
Third, I wonder why you chose these values? Wouldn't it be just as interesting to test the compiler with a signed -1, which will be stored as hex 7F, verses an unsigned 0. This time -1 is less than 0, but the twos compliment storage reverses the logic, because 127 > 0. So, if the RAM contents are compared, when enquiring if -1 > 0, in that case the RAM contents are 127 and 0. This seems churlish though, since assembler instructions are supplied so the CPU can handle signed values at the circuit level. Again, software can be coded to cover this eventuality even if the CPU didn't.
With the values chosen, storage-wise, a signed 1 is stored as 1 and an unsigned 255 is stored as 255. This is where pawn promotion comes in. I don't like the term 'promotion' too much. I prefer cast or, coming from Algol, coercion. Reason being, neither format is superior. I suppose this must refer to C++ compiler conversion, meaning values can be promoted Up the conceptual chain of storage types, but not down it? Right?
So, what about this promotion? I don't know how C++ works internally but surely the logic would make sense if it simply compared the intended senses? Why suppose it would promote the 255 to signed first, then compare, thus destroying the sense of the assignments? Why suppose it's promoted at all? Why can't both values be simply compared as they are? It's the return value of the call to > which is an int, but surely the values passed to it can be anything it accepts as being reasonable to logic? Signed and unsigned values can be compared, it's a dyadic operator, so you only need four permutations for type char. Mmmm.... I'd have to try it. Compiler's are famous for breaking the rules they impose on programmers such as operator overloading, so internally there needn't be 'really' a c function for every possible permutation of acceptable numeric type v every possible type.
*****
Fuck off.
Those questions are completely pointless. The standard says what the standard says and a compiler has to implement the standard correctly.
Kalum Batsch
Those questions aren't (necessarily) about the standard, they refer more to the speaker's reasoning than anything else.
Meanwhile it's stupid to pretend standards exist in an untouchable space where their sense must not be questioned.
If your reasoning were true we'd still write everything in Fortran.
Why don't we?
Because the standard is flawed.
Same with Algol, which became bcpl, which became C which became C++, which became Java... PHP, ECMCAScript.... which eventually all gave way to functionality.
You live and learn, that's how, and why, standards evolve.
Crescendo
You wrote a long screed that basically says, I haven't bothered to find out how it works but I have lots of ideas about how it *should* work, so everybody pay attention to me!
"First off, why declare the function an int? When you're returning the result of a logical query, surely it's more apposite for the return type to be bool?"
Because there is no "bool" in C (at least before C99).
Kalum Batsch
Are you just Googling for this as you go along like a blind man feeling around in the dark for where to go next?
It ISN'T a presentation on C, it's a presentation on Optimising Compilers, in tihs case LLVM, which ISN'T a C compiler, IS most famous for it's C++ front end, and WAS developed long after primitive Bool types were very much a part of the C++ current standard.
Your argument is refuting something I didn't say.
What will you do next? Attack me for insiting the Loch Ness Monster has purple hair?