It is the job of the language to ensure that language primitives are reusable and composable.
I think this would apply to whatever mechanism is designed to describe a loop's iteration space.
1,316 karma · joined March 25, 2012
I think this would apply to whatever mechanism is designed to describe a loop's iteration space.
It is incredibly useful to talk about a loop's trip count or the values an induction variable can have.
It turns out that taking advantage of signed overflow lets us do that in more places, a boon to all the programs which don't dynamically execute signed overflow.
The tradeoff, however, is that the programing model gets way more complicated. I have talked to the engineer who introduced this optimizing power to our compiler and he sorta regrets it.
IMO, we need better, higher level ways of talking about a loop's iteration space. Today, in C or C++, we are forced to represent the iteration space of a loop using the language's algebra. This is severely limiting when each operation on a signed type might introduce UB. With a higher level mechanism, we can separate the behavior that we want for loops from the behavior we want for everything else in a nice, clean way.
The sharpest thorn, to me, is: what happens when you are running inside the critical section and your thread gets preempted?
Well, now the next thread which tries to acquire the lock is stuck waiting. But waiting for what? Waiting for the original thread to get scheduled.
Now, the OS has no idea that the original thread should get scheduled again and is free to continue scheduling more and more work items.
Fortunately for the lock in this article, and most other locks which spin, it is adaptive and will not spin for too long. But how long is long enough? If the spin is timed for a few loads and stores, then all is probably well as spins will not be attempted for very long.
I wonder how these locks figure out how long they should spin? In the nasty case I previously mentioned, you'd want to spin for a very short while to avoid large amounts of waste. But spins which are too short lead to higher lock/unlock latency if the lock was held for any appreciable amount of time.
This leads me to the following conclusion: spinning inevitable leads to _some_ number of wasted CPU cycles and therefore increased latency.
I'm curious as to how the amount of spinning was chosen.
SSA is a program representation which is easy for compilers to analyze and optimize. See https://en.wikipedia.org/wiki/Static_single_assignment_form for more.
bool f(bool b) {
int x;
try {
if (b) {
x = 2;
throw 0;
}
x = 4;
throw 0.0;
} catch (...) {
}
return x & 1;
}
Out of curiosity, can you give details regarding how your EH representation looks like in SSA?
$ clang t.cpp -target x86_64-pc-win32 -S -emit-llvm -o - | opt -S -sroa -instcombine | grep 'ret i1'
ret i1 falseIt also sounds like they have something like LLVM's InstCombine pass, it'll be interesting to compare which cases they handle. Despite it being a peephole pass, InstCombine is actually one of the most important scalar optimizations in LLVM's arsenal.
I also wonder if they form SSA in the face of C++ and/or SEH exceptions.
Like if you have something like:
bool f() {
int x = 2;
try {
throw 0;
} catch (...) {
x = 4;
}
return x & 1;
}
We are still using X, still using terminals powered by control codes, etc.
Rob probably sees things like LANG and LC_ALL as bugs. His fix was UTF-8 everywhere, always. Where is Linux? Still in bag-of-bytes-o-rama.
http://blogs.msdn.com/b/slavao/archive/2005/02/05/367816.asp...
#pragma weak, asm labels, always_inline, debug information, attribute regparm, inline assembly, etc...
All of this is doable via incremental lowering from the AST (this is how clang does it) but it is fairly painful.
Even the relatively banal:
enum e;
void (*fp)(enum e);
enum e { v = 1ULL << 32 };
This would be akin to asking why do we need a C++-specific AST and a Swift-specific AST.
Work is ongoing to support features like COMDAT folding.
First off, some frontend features are only feasible by changing LLVM itself. This is uncommon but ultimately not rare at all, this is where IR features like musttail, inalloca, safestack and segmented stacks originated. It is unlikely that swift will never need such a change.
Secondly, it would directly contradict what Chris Lattner announced at WWDC: They are going to accept contributions (both ideas and code) from others.
Finally, a frontend which generates LLVM IR has a very tight dependency on LLVM itself. LLVM IR is allowed to freely evolve which, in turn, causes APIs to change or disappear. It is much easier to deal with this if your code lives on llvm.org because the community is obliged to make sure your code continues to work. People fix polly, lldb, clang, etc. if their change to LLVM broke them.
> Apple's announcement remained completely silent on patents, and we should expect the chosen non-copyleft license will not contain a patent grant.
The LLVM project makes it's stance on patents quite clear [1].
AFAIK, Microsoft hasn't contributed to any of these ends. I, for one, hope that they do.
Here is their implementation of name mangling: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Micros...
Here is their implementation of record layout: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Record...
Here is their implementation of vtable generation: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTable...
Here is their implementation of RTTI: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/Mi...
Here is their implementation of C++ throw metadata: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/Mi...
Yeah, I might have to agree that American art and beauty might not best be showcased at liquor stores but lets not use that brush to paint the rest of the country.
This wouldn't be a bad thing if the API wasn't broken by design. It is opening itself up to 'time of check to time of use' bugs because it is completely oriented around paths.
I can't believe that this was approved.
I was a professional file-system hacker until quite recently and this API seems like exactly the wrong thing.
Intel ships a compiler based on Clang: http://llvm.org/devmtg/2014-04/PDFs/Posters/ClangIntel.pdf
This means they get clang's ridiculously conforming implementation with icc's performance.