emscripten-fastcomp/lib/ExecutionEngine/JIT, branch master

Make APFloat constructor require explicit semantics.

2013-01-22T09:46:31Z

Previously we tried to infer it from the bit width size, with an added IsIEEE argument for the PPC/IEEE 128-bit case, which had a default value. This default value allowed bugs to creep in, where it was inappropriate. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173138 91177308-0d34-0410-b5e6-96231b3b80d8

Fix More Casts

2013-01-14T21:04:44Z

Properly cast some more code that triggered cast-away-const errors. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172469 91177308-0d34-0410-b5e6-96231b3b80d8

Fix bug in exception table allocation (PR13678)

2013-01-11T16:33:30Z

Patch by Michael Muller. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172214 91177308-0d34-0410-b5e6-96231b3b80d8

Move all of the header files which are involved in modelling the LLVM IR

2013-01-02T11:36:10Z

into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8

Remove duplicate includes.

2012-12-21T17:06:44Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170902 91177308-0d34-0410-b5e6-96231b3b80d8

Use the new script to sort the includes of every file under lib.

2012-12-03T16:50:05Z

Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8

Interface changes to allow RuntimeDyld memory managers to set memory permissions after an object has been loaded.

2012-11-15T23:50:01Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168114 91177308-0d34-0410-b5e6-96231b3b80d8

Revert the majority of the next patch in the address space series:

2012-11-01T09:14:31Z

r165941: Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis. Despite this commit log, this change primarily changed stuff outside of VMCore, and those changes do not carry any tests for correctness (or even plausibility), and we have consistently found questionable or flat out incorrect cases in these changes. Most of them are probably correct, but we need to devise a system that makes it more clear when we have handled the address space concerns correctly, and ideally each pass that gets updated would receive an accompanying test case that exercises that pass specificaly w.r.t. alternate address spaces. However, from this commit, I have retained the new C API entry points. Those were an orthogonal change that probably should have been split apart, but they seem entirely good. In several places the changes were very obvious cleanups with no actual multiple address space code added; these I have not reverted when I spotted them. In a few other places there were merge conflicts due to a cleaner solution being implemented later, often not using address spaces at all. In those cases, I've preserved the new code which isn't address space dependent. This is part of my ongoing effort to clean out the partial address space code which carries high risk and low test coverage, and not likely to be finished before the 3.2 release looms closer. Duncan and I would both like to see the above issues addressed before we return to these changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167222 91177308-0d34-0410-b5e6-96231b3b80d8

Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis.

2012-10-15T16:24:29Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165941 91177308-0d34-0410-b5e6-96231b3b80d8

Remove buggy classof().

2012-10-11T23:30:38Z

This classof() is effectively saying that a MachineCodeEmitter "is-a" JITEmitter, but JITEmitter is in fact a descendant of MachineCodeEmitter, so this is not semantically correct. Consequently, none of the assertions that rely on these classof() actualy check anything. Remove the RTTI (which didn't actually check anything) and use static_cast<> instead. Post-Mortem Bug Analysis ======================== Cause of the bug ---------------- r55022 appears to be the source of the classof() and assertions removed by this commit. It aimed at removing some dynamic_cast<> that were solely in the assertions. A typical diff hunk from that commit looked like: - assert(dynamic_cast(MCE) && "Unexpected MCE?"); - JITEmitter *JE = static_cast(getCodeEmitter()); + assert(isa(MCE) && "Unexpected MCE?"); + JITEmitter *JE = cast(getCodeEmitter()); Hence, the source of the bug then seems to be an attempt to replace dynamic_cast<> with LLVM-style RTTI without properly setting up the class hierarchy for LLVM-style RTTI. The bug therefore appears to be simply a "thinko". What initially indicated the presence of the bug ------------------------------------------------ After implementing automatic upcasting for isa<>, classof() functions of the form static bool classof(const Foo *) { return true; } were removed, since they only serve the purpose of optimizing statically-OK upcasts. A subsequent recompilation triggered a build failure on the isa<> tests within the removed asserts, since the automatic upcasting (correctly) failed to substitute this classof(). Key to pinning down the root cause of the bug --------------------------------------------- After being alerted to the presence of the bug, some thought about the semantics which were being asserted by the buggy classof() revealed that it was incorrect. How the bug could have been prevented ------------------------------------- This bug could have been prevented by better documentation for how to set up LLVM-style RTTI. This should be solved by the recently added documentation HowToSetUpLLVMStyleRTTI. However, this bug suggests that the documentation should clearly explain the contract that classof() must fulfill. The HowToSetUpLLVMStyleRTTI already explains this contract, but it is a little tucked away. A future patch will expand that explanation and make it more prominent. There does not appear to be a simple way to have the compiler prevent this bug, since fundamentally it boiled down to a spurious classof() where the programmer made an erroneous statement about the conversion. This suggests that perhaps the interface to LLVM-style RTTI of classof() is not the best. There is already some evidence for this, since in a number of places Clang has classof() forward to classofKind(Kind K) which evaluates the cast in terms of just the Kind. This could probably be generalized to simply a `static const Kind MyKind;` field in leaf classes and `static const Kind firstMyKind, lastMyKind;` for non-leaf classes, and have the rest of the work be done inside Casting.h, assuming that the Kind enum is laid out in a preorder traversal of the inheritance tree. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165764 91177308-0d34-0410-b5e6-96231b3b80d8