Add support for specifying alignment and size of setjmp jmpbufs.
No targets currently do anything with this information, nor is it presrved
in the bytecode representation. That's coming up next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24196 91177308-0d34-0410-b5e6-96231b3b80d8
pointer marking the end of the list, the zero *must* be cast to the pointer
type. An un-cast zero is a 32-bit int, and at least on x86_64, gcc will
not extend the zero to 64 bits, thus allowing the upper 32 bits to be
random junk.
The new END_WITH_NULL macro may be used to annotate a such a function
so that GCC (version 4 or newer) will detect the use of un-casted zero
at compile time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23888 91177308-0d34-0410-b5e6-96231b3b80d8
These changes modify the makefiles so that the output of flex and bison are
placed in the SRC directory, not the OBJ directory. It is intended that they
be checked in as any other LLVM source so that platforms without convenient
access to flex/bison can be compiled. From now on, if you change a .y or
.l file you *must* also commit the generated .cpp and .h files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23115 91177308-0d34-0410-b5e6-96231b3b80d8
defined in function constant pools. The assembler grammar has long
disallowed functions from having constant pools, so all of this stuff is
dead.
This makes it an immediate error for functions to refer to nonexisting
types, fixing Regression/Verifier/2005-03-21-UndefinedTypeReference.ll.
Before, references to non-existing types in functions would only be
detected when the subsequent function was parsed, due to the call to
"ResolveTypes". "ResolveTypes" has not resolved any types for a long time,
instead it emitted an error message if no resolved types are left. Since
the only caller of this method is in the module code, just inline it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20726 91177308-0d34-0410-b5e6-96231b3b80d8
using Function::arg_{iterator|begin|end}. Likewise Module::g* -> Module::global_*.
This patch is contributed by Gabor Greif, thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20597 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure to check isValueValidForType on floating point constants and give \
an error if the value is not valid, otherwise it would assert in the VMCore
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@18584 91177308-0d34-0410-b5e6-96231b3b80d8
Correct the dependency of the Lexer.o file on the constructed
llvmAsmParser.h header file. It is not the Lexer.cpp file that depends on
the header, its the output of compiling Lexer.cpp, Lexer.o
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17289 91177308-0d34-0410-b5e6-96231b3b80d8
the strings for basic block labels in some cases. This amounted to about
120K of memory for namd, a medium sized program.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17262 91177308-0d34-0410-b5e6-96231b3b80d8
error. We'll strategize on this when we have multiple front ends to deal
with. For now llvm-ld just runs a standard set of transforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16333 91177308-0d34-0410-b5e6-96231b3b80d8
Move include/Config and include/Support into include/llvm/Config,
include/llvm/ADT and include/llvm/Support. From here on out, all LLVM
public header files must be under include/llvm/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16137 91177308-0d34-0410-b5e6-96231b3b80d8
* Simplify a lot of code because type's cannot be in function symbol tables
* Fix memory leaks in handling of redefined function prototypes
* Don't use SymbolTable directly for stuff that we can go through the Module
for.
* Fix some minor bugs on obscure testcases like:
test/Feature/globalredefinition.ll
* Do not create GlobalVariable objects for forward referenced Functions!
* When forward referencing a function in a constant expression, do not create
a placeholder, add a bunch of references to it, then turn around and
replaceAllUsesOfWith on it with a new global, deleting the placeholder.
Instead, when we find the real definition of the global, just use the
placeholder instead of creating a new object.
This substantially simplifies the asmwriter and should even speed it up on
cases heavy in constantexprs (like C++, Java, MSIL)...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14830 91177308-0d34-0410-b5e6-96231b3b80d8
replaceAllUsesWith'ing any forward references, just use the forward
reference if it exists.
This introduces GetForwardRefForGlobal, which will eventually completely
replace the horrible DeclareNewGlobalValue function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14828 91177308-0d34-0410-b5e6-96231b3b80d8
to substantially simplify the result. In particular, we no longer create
GlobalVariables and then immediately destroy them when they are duplciate
definitions.
The real point of this patch though is that it gets us closer to the
DeclareNewGlobalValue calls...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14827 91177308-0d34-0410-b5e6-96231b3b80d8
This gives us only a single call site for setValueNameMergingDuplicates.
The next stage is the start merging them together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14811 91177308-0d34-0410-b5e6-96231b3b80d8
Since the stupid '%X = const int 4' thing is gone, we can now simplify
setValueNameMergingDuplicates a bit more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14810 91177308-0d34-0410-b5e6-96231b3b80d8
for a basic block, use it when the block is defined instead of deleting it
and creating a new one. Also, only create at most ONE forward reference
for any block, instead of one for each forward reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14807 91177308-0d34-0410-b5e6-96231b3b80d8
forward reference blocks if they have been created (instead of creating a new
block, replaceAllUsesOfWith, then nuking the placeholder). This is not yet
implemented.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14791 91177308-0d34-0410-b5e6-96231b3b80d8
just to keep track of some per-object state! Gaah! Whoever wrote this stuff...
oh wait, that would be me. Never mind.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14790 91177308-0d34-0410-b5e6-96231b3b80d8
the funciton symbol table to check for conflicts instead of having to
keep a shadow named LocalSymtab. Totally eliminate LocalSymtab. Verified
that this did not cause a regression on the testcase for PR107.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14788 91177308-0d34-0410-b5e6-96231b3b80d8
1. Split setValueName into two separate functions, one that is only used
at function scope and doesn't have to deal with duplicates, and one
that can be used either at global or function scope but that does deal
with conflicts. Conflicts were only in there because of the crappy old
CFE and probably should be entirely eliminated.
2. Insert BasicBlock's into the parent functions when they are created
instead of when they are complete. This effects name lookup (for the
better), which will be exploited in the next patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14787 91177308-0d34-0410-b5e6-96231b3b80d8
function to llvmAsmParser.y and then use it in the one place in the grammar
that needs it. Also had to make Type::setName public because setTypeName
needs it in order to retain compatibility with setValueName.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13795 91177308-0d34-0410-b5e6-96231b3b80d8
types and can have arbitrary 32- and 64-bit integer types indexing into
sequential types.
Auto-upgrade .ll files that use ubytes to index into structures to use uint's.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12652 91177308-0d34-0410-b5e6-96231b3b80d8
in this for programs with lots of types (like the testcase in PR224).
The problem was that the type ID that the outer vector was using was not
very dense (as many types are getting resolved), so the vector is large
and gets reallocated a lot.
Since there are a lot of values in the program (the .ll file is 10M),
each reallocation has to copy the subvectors, which is also quite slow
(this wouldn't be a problem if C++ supported move semantics, but it
doesn't, at least not yet :(
Changing the outer data structure to a map speeds a release build of
llvm-as up from 11.21s to 5.13s on the testcase in PR224.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11244 91177308-0d34-0410-b5e6-96231b3b80d8
type at the same time, resolve the upreferences to each other before resolving
it to the outer type. This shaves off some time from the testcase in PR224, from
25.41s -> 21.72s.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11241 91177308-0d34-0410-b5e6-96231b3b80d8
