Major reorganization. This patch introduces the signedness changes for
the new integer types (i8, i16, i32, i64) which replace the old signed
versions (ubyte, sbyte, ushort, short, etc). This patch also implements
the function type parameter attributes feature. Together these conspired
to introduce new reduce/reduce errors into the grammar. Consequently, it
was necessary to introduce a new keyword into the grammar in order to
disambiguate. Without this, yacc would make incorrect shift/reduce and
reduce/reduce decisions and fail to parse the intended assembly.
Changes in assembly:
1. The "implementation" keyword is superfluous but still supported. You
can use it as a sentry which will ensure there are no remaining up
reference types. However, this is optional as those checks are also
performed elsewhere.
2. Parameter attributes are now implemented using an at sign to
indicate the attribute. The attributes are placed after the type
in a function declaration or after the argument value in a function
call. For example:
i8 @sext %myfunc(i16 @zext)
call i8 @sext %myfunc(i16 @zext %someVal)
The facility is available for supporting additional attributes and
they can be combined using the @(attr1,attr2,attr3) syntax. Right
now the only two supported are @sext and @zext
3. Functions must now be defined with the "define" keyword which is
analagous to the "declare" keyword for function declarations. The
introduction of this keyword disambiguates situations where a
named result type is confused with a new type or gvar definition.
For example:
%MyType = type i16
%MyType %func(%MyType) { ... }
With the introduction of optional parameter attributes between
the function name and the function result type, yacc will pick
the wrong rule to reduce unless it is disambiguated with "define"
before the function definition, as in:
define %MyType @zext %func(%MyType %someArg) { ... }
llvm-svn: 32781
Remove all grammar conflicts from assembly parsing. This change involves:
1. Making the "type" keyword not a primitive type (removes several
reduce/reduce conflicts)
2. Being more specific about which linkage types are allowed for functions
and global variables. In particular "appending" can no longer be
specified for a function. A differentiation was made between the various
internal and external linkage types.
3. Introduced the "define" keyword which is now required when defining a
function. This disambiguates several cases where a named function return
type could get confused with the definition of a new type. Using the
keyword eliminates all shift/reduce conflicts and the remaining
reduce/reduce conflicts.
These changes are necessary to implement the function parameter attributes
that will be introduced soon. Adding the function parameter attributes in
the presence of the shift/reduce and reduce/reduce conflicts led to severe
ambiguities that caused the parser to report syntax errors that needed to
be resolved. This patch resolves them.
llvm-svn: 32770
This patch removes the SetCC instructions and replaces them with the ICmp
and FCmp instructions. The SetCondInst instruction has been removed and
been replaced with ICmpInst and FCmpInst.
llvm-svn: 32751
greater than MAX_INT64 for signed integers. This is now valid and is just
waiting for the distinction between signed and unsigned to go away.
llvm-svn: 32716
constant lists. This is just an internal change to the parser in
preparation for some backwards compatibility code that is to follow.
This will allow things like "uint 4000000000" to retain the unsignedness
of the integer constant as the value moves through the parser. In the
future, all integer types will be signless but parsing "uint" and friends
will be retained for backwards compatibility.
llvm-svn: 31964
The long awaited CAST patch. This introduces 12 new instructions into LLVM
to replace the cast instruction. Corresponding changes throughout LLVM are
provided. This passes llvm-test, llvm/test, and SPEC CPUINT2000 with the
exception of 175.vpr which fails only on a slight floating point output
difference.
llvm-svn: 31931
Retain the signedness of the old integer types in a new TypeInfo structure
so that it can be used in the grammar to implement auto-upgrade of things
that depended on signedness of types. This doesn't implement any new
functionality in the AsmParser, its just plumbing for future changes.
llvm-svn: 31866
This patch converts the old SHR instruction into two instructions,
AShr (Arithmetic) and LShr (Logical). The Shr instructions now are not
dependent on the sign of their operands.
llvm-svn: 31542
Turn on -Wunused and -Wno-unused-parameter. Clean up most of the resulting
fall out by removing unused variables. Remaining warnings have to do with
unused functions (I didn't want to delete code without review) and unused
variables in generated code. Maintainers should clean up the remaining
issues when they see them. All changes pass DejaGnu tests and Olden.
llvm-svn: 31380
Make necessary changes to support DIV -> [SUF]Div. This changes llvm to
have three division instructions: signed, unsigned, floating point. The
bytecode and assembler are bacwards compatible, however.
llvm-svn: 31195
This patch implements the first increment for the Signless Types feature.
All changes pertain to removing the ConstantSInt and ConstantUInt classes
in favor of just using ConstantInt.
llvm-svn: 31063
a better encoding of the targets data layout, rather than trying to guess it
from the endianness and pointersize like before.
Update the generated files.
llvm-svn: 31031
The result of yyparse() was not being checked. When YYERROR or YYABORT is
called it causes yyparse() to return 1 to indicate the error. The code was
silently ignoring this situation because it previously expected either an
exception or a null ParserResult to indicate an error. The patch corrects
this situation.
llvm-svn: 30834
Errors are generated with the YYERROR macro which can only be called from
a production (inside yyparse) because of the goto statement in the macro.
This lead to several situations where GEN_ERROR was not called but
GenerateError was used instead (because it doesn't use YYERROR). However,
in such situations, catching the error much later (e.g. at the end of
the production) is not sufficient because LLVM can assert on invalid data
before the end of the production is reached. The solution is to ensure that
the CHECK_FOR_ERROR macro (which invokes YYERROR if there's an error) is
used as soon as possible after a call to GenerateError has been made.
llvm-svn: 30650
DLL* linkages got full (I hope) codegeneration support in C & both x86
assembler backends.
External weak linkage added for future use, we don't provide any
codegeneration, etc. support for it.
llvm-svn: 30374
1. Actually turn on -fno-exceptions in libraries that do not have the
REQUIRES_EH option in their Makefile. The following library file size
savings were made (DEBUG):
libLLVMDataStructure.a 525K
libLLVMCore.a 380K
libLLVMCodeGen.a 350K
libLLVMTransformUtils.a 305K
libLLVMScalarOpts.a 270K
libLLVMAnalysis.a 247K
libLLVMSelectionDAG.a 233K
libLLVMipo.a 175K
LLVMX86.o 123K
LLVMPPC.o 81K
libLLVMipa.a 17K
TOTAL 2,706K
Note that the savings is actually a little larger than this because
I didn't count any of the libraries that had small changes.
2. Remove REQUIRES_EH from the AsmParser library as it is now exception
free. This resulted in a nearly 78K drop in the size of the debug
library for AsmParser.
llvm-svn: 29767
Rid the Assembly Parser of exceptions. This is a really gross hack but it
will do until the Assembly Parser is re-written as a recursive descent.
The basic premise is that wherever the old "ThrowException" function was
called (new name: GenerateError) we set a flag (TriggerError). Every
production checks that flag and calls YYERROR if it is set. Additionally,
each call to ThrowException in the grammar is replaced with GEN_ERROR
which calls GenerateError and then YYERROR immediately. This prevents
the remaining production from continuing after an error condition.
llvm-svn: 29763
This patch is an incremental step towards supporting a flat symbol table.
It de-overloads the intrinsic functions by providing type-specific intrinsics
and arranging for automatically upgrading from the old overloaded name to
the new non-overloaded name. Specifically:
llvm.isunordered -> llvm.isunordered.f32, llvm.isunordered.f64
llvm.sqrt -> llvm.sqrt.f32, llvm.sqrt.f64
llvm.ctpop -> llvm.ctpop.i8, llvm.ctpop.i16, llvm.ctpop.i32, llvm.ctpop.i64
llvm.ctlz -> llvm.ctlz.i8, llvm.ctlz.i16, llvm.ctlz.i32, llvm.ctlz.i64
llvm.cttz -> llvm.cttz.i8, llvm.cttz.i16, llvm.cttz.i32, llvm.cttz.i64
New code should not use the overloaded intrinsic names. Warnings will be
emitted if they are used.
llvm-svn: 25366
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.
llvm-svn: 24196
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.
llvm-svn: 23888
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.
llvm-svn: 23115
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.
llvm-svn: 20726
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
llvm-svn: 18584
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
llvm-svn: 17289
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/.
llvm-svn: 16137
* 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)...
llvm-svn: 14830
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.
llvm-svn: 14828
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...
llvm-svn: 14827
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.
llvm-svn: 14807
forward reference blocks if they have been created (instead of creating a new
block, replaceAllUsesOfWith, then nuking the placeholder). This is not yet
implemented.
llvm-svn: 14791
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.
llvm-svn: 14788
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.
llvm-svn: 14787
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.
llvm-svn: 13795
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.
llvm-svn: 12652
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.
llvm-svn: 11244
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.
llvm-svn: 11241
contains the type we are looking for, just search the immediately used types.
We can only do this because we keep the "current" type in the nesting level
as we decrement upreferences.
This change speeds up the testcase in PR224 from 50.4s to 22.08s, not
too shabby.
llvm-svn: 11221
This introduces one more innoculous shift-reduce conflict, but will REALLY
help the type names generated by the C++ frontend, which wants to use all
kinds of crazy stuff.
llvm-svn: 8050
- Changed parser to always use parenthesis on ConstExprs to be consistent
- Parser now passes TRUE and FALSE tokens as a special case of the ConstExpr
machinery instead of a special case of constant int stuff
- Fix the AsmParser to use ValueRef ::= ConstExpr, and remove
ResolvedVal ::= ConstExpr this allows constexprs to be used in PHI nodes
llvm-svn: 3362
* Correctly delete TypeHandles in AsmParser. In addition to not leaking
memory, this prevents a bug that could have occurred when a type got
resolved that the constexpr was using
* Check for errors in the AsmParser instead of hitting assertion failures
deep in the code
* Simplify the interface to the ConstantExpr class, removing unneccesary
parameters to the ::get* methods.
* Rename the 'getelementptr' version of ConstantExpr::get to
ConstantExpr::getGetElementPtr
llvm-svn: 3161
