2006-10-18 10:21:48 +08:00
|
|
|
#define yy_create_buffer llvmAsm_create_buffer
|
|
|
|
#define yy_delete_buffer llvmAsm_delete_buffer
|
|
|
|
#define yy_scan_buffer llvmAsm_scan_buffer
|
|
|
|
#define yy_scan_string llvmAsm_scan_string
|
|
|
|
#define yy_scan_bytes llvmAsm_scan_bytes
|
|
|
|
#define yy_flex_debug llvmAsm_flex_debug
|
|
|
|
#define yy_init_buffer llvmAsm_init_buffer
|
|
|
|
#define yy_flush_buffer llvmAsm_flush_buffer
|
|
|
|
#define yy_load_buffer_state llvmAsm_load_buffer_state
|
|
|
|
#define yy_switch_to_buffer llvmAsm_switch_to_buffer
|
|
|
|
#define yyin llvmAsmin
|
|
|
|
#define yyleng llvmAsmleng
|
|
|
|
#define yylex llvmAsmlex
|
|
|
|
#define yyout llvmAsmout
|
|
|
|
#define yyrestart llvmAsmrestart
|
|
|
|
#define yytext llvmAsmtext
|
|
|
|
#define yylineno llvmAsmlineno
|
|
|
|
|
|
|
|
#line 20 "Lexer.cpp"
|
2006-11-27 09:05:10 +08:00
|
|
|
/* A lexical scanner generated by flex*/
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* Scanner skeleton version:
|
|
|
|
* $Header$
|
|
|
|
*/
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
#define FLEX_SCANNER
|
|
|
|
#define YY_FLEX_MAJOR_VERSION 2
|
|
|
|
#define YY_FLEX_MINOR_VERSION 5
|
|
|
|
|
|
|
|
#include <stdio.h>
|
2006-11-27 09:05:10 +08:00
|
|
|
#include <unistd.h>
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* cfront 1.2 defines "c_plusplus" instead of "__cplusplus" */
|
|
|
|
#ifdef c_plusplus
|
|
|
|
#ifndef __cplusplus
|
|
|
|
#define __cplusplus
|
2006-09-15 02:25:26 +08:00
|
|
|
#endif
|
|
|
|
#endif
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-09-15 02:25:26 +08:00
|
|
|
#ifdef __cplusplus
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
|
|
|
/* Use prototypes in function declarations. */
|
|
|
|
#define YY_USE_PROTOS
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
/* The "const" storage-class-modifier is valid. */
|
|
|
|
#define YY_USE_CONST
|
|
|
|
|
|
|
|
#else /* ! __cplusplus */
|
|
|
|
|
|
|
|
#if __STDC__
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_USE_PROTOS
|
2005-08-28 02:50:39 +08:00
|
|
|
#define YY_USE_CONST
|
|
|
|
|
|
|
|
#endif /* __STDC__ */
|
|
|
|
#endif /* ! __cplusplus */
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef __TURBOC__
|
|
|
|
#pragma warn -rch
|
|
|
|
#pragma warn -use
|
|
|
|
#include <io.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#define YY_USE_CONST
|
|
|
|
#define YY_USE_PROTOS
|
|
|
|
#endif
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
#ifdef YY_USE_CONST
|
|
|
|
#define yyconst const
|
|
|
|
#else
|
|
|
|
#define yyconst
|
|
|
|
#endif
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
#define YY_PROTO(proto) proto
|
|
|
|
#else
|
|
|
|
#define YY_PROTO(proto) ()
|
|
|
|
#endif
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
/* Returned upon end-of-file. */
|
|
|
|
#define YY_NULL 0
|
|
|
|
|
|
|
|
/* Promotes a possibly negative, possibly signed char to an unsigned
|
|
|
|
* integer for use as an array index. If the signed char is negative,
|
|
|
|
* we want to instead treat it as an 8-bit unsigned char, hence the
|
|
|
|
* double cast.
|
|
|
|
*/
|
|
|
|
#define YY_SC_TO_UI(c) ((unsigned int) (unsigned char) c)
|
|
|
|
|
|
|
|
/* Enter a start condition. This macro really ought to take a parameter,
|
|
|
|
* but we do it the disgusting crufty way forced on us by the ()-less
|
|
|
|
* definition of BEGIN.
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
#define BEGIN yy_start = 1 + 2 *
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* Translate the current start state into a value that can be later handed
|
|
|
|
* to BEGIN to return to the state. The YYSTATE alias is for lex
|
|
|
|
* compatibility.
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_START ((yy_start - 1) / 2)
|
2005-08-28 02:50:39 +08:00
|
|
|
#define YYSTATE YY_START
|
|
|
|
|
|
|
|
/* Action number for EOF rule of a given start state. */
|
|
|
|
#define YY_STATE_EOF(state) (YY_END_OF_BUFFER + state + 1)
|
|
|
|
|
|
|
|
/* Special action meaning "start processing a new file". */
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_NEW_FILE yyrestart( yyin )
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
#define YY_END_OF_BUFFER_CHAR 0
|
|
|
|
|
|
|
|
/* Size of default input buffer. */
|
|
|
|
#define YY_BUF_SIZE (16384*64)
|
|
|
|
|
|
|
|
typedef struct yy_buffer_state *YY_BUFFER_STATE;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
extern int yyleng;
|
|
|
|
extern FILE *yyin, *yyout;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
#define EOB_ACT_CONTINUE_SCAN 0
|
|
|
|
#define EOB_ACT_END_OF_FILE 1
|
|
|
|
#define EOB_ACT_LAST_MATCH 2
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* The funky do-while in the following #define is used to turn the definition
|
|
|
|
* int a single C statement (which needs a semi-colon terminator). This
|
|
|
|
* avoids problems with code like:
|
|
|
|
*
|
|
|
|
* if ( condition_holds )
|
|
|
|
* yyless( 5 );
|
|
|
|
* else
|
|
|
|
* do_something_else();
|
|
|
|
*
|
|
|
|
* Prior to using the do-while the compiler would get upset at the
|
|
|
|
* "else" because it interpreted the "if" statement as being all
|
|
|
|
* done when it reached the ';' after the yyless() call.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Return all but the first 'n' matched characters back to the input stream. */
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
#define yyless(n) \
|
|
|
|
do \
|
|
|
|
{ \
|
2006-10-18 10:21:48 +08:00
|
|
|
/* Undo effects of setting up yytext. */ \
|
|
|
|
*yy_cp = yy_hold_char; \
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RESTORE_YY_MORE_OFFSET \
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_c_buf_p = yy_cp = yy_bp + n - YY_MORE_ADJ; \
|
|
|
|
YY_DO_BEFORE_ACTION; /* set up yytext again */ \
|
2005-08-28 02:50:39 +08:00
|
|
|
} \
|
|
|
|
while ( 0 )
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#define unput(c) yyunput( c, yytext_ptr )
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-11-27 09:05:10 +08:00
|
|
|
/* Some routines like yy_flex_realloc() are emitted as static but are
|
|
|
|
not called by all lexers. This generates warnings in some compilers,
|
|
|
|
notably GCC. Arrange to suppress these. */
|
|
|
|
#ifdef __GNUC__
|
|
|
|
#define YY_MAY_BE_UNUSED __attribute__((unused))
|
|
|
|
#else
|
|
|
|
#define YY_MAY_BE_UNUSED
|
|
|
|
#endif
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
/* The following is because we cannot portably get our hands on size_t
|
|
|
|
* (without autoconf's help, which isn't available because we want
|
|
|
|
* flex-generated scanners to compile on their own).
|
|
|
|
*/
|
2006-09-15 02:25:26 +08:00
|
|
|
typedef unsigned int yy_size_t;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
struct yy_buffer_state
|
|
|
|
{
|
|
|
|
FILE *yy_input_file;
|
|
|
|
|
|
|
|
char *yy_ch_buf; /* input buffer */
|
|
|
|
char *yy_buf_pos; /* current position in input buffer */
|
|
|
|
|
|
|
|
/* Size of input buffer in bytes, not including room for EOB
|
|
|
|
* characters.
|
|
|
|
*/
|
|
|
|
yy_size_t yy_buf_size;
|
|
|
|
|
|
|
|
/* Number of characters read into yy_ch_buf, not including EOB
|
|
|
|
* characters.
|
|
|
|
*/
|
|
|
|
int yy_n_chars;
|
|
|
|
|
|
|
|
/* Whether we "own" the buffer - i.e., we know we created it,
|
|
|
|
* and can realloc() it to grow it, and should free() it to
|
|
|
|
* delete it.
|
|
|
|
*/
|
|
|
|
int yy_is_our_buffer;
|
|
|
|
|
|
|
|
/* Whether this is an "interactive" input source; if so, and
|
|
|
|
* if we're using stdio for input, then we want to use getc()
|
|
|
|
* instead of fread(), to make sure we stop fetching input after
|
|
|
|
* each newline.
|
|
|
|
*/
|
|
|
|
int yy_is_interactive;
|
|
|
|
|
|
|
|
/* Whether we're considered to be at the beginning of a line.
|
|
|
|
* If so, '^' rules will be active on the next match, otherwise
|
|
|
|
* not.
|
|
|
|
*/
|
|
|
|
int yy_at_bol;
|
|
|
|
|
|
|
|
/* Whether to try to fill the input buffer when we reach the
|
|
|
|
* end of it.
|
|
|
|
*/
|
|
|
|
int yy_fill_buffer;
|
|
|
|
|
|
|
|
int yy_buffer_status;
|
|
|
|
#define YY_BUFFER_NEW 0
|
|
|
|
#define YY_BUFFER_NORMAL 1
|
|
|
|
/* When an EOF's been seen but there's still some text to process
|
|
|
|
* then we mark the buffer as YY_EOF_PENDING, to indicate that we
|
|
|
|
* shouldn't try reading from the input source any more. We might
|
|
|
|
* still have a bunch of tokens to match, though, because of
|
|
|
|
* possible backing-up.
|
|
|
|
*
|
|
|
|
* When we actually see the EOF, we change the status to "new"
|
2006-10-18 10:21:48 +08:00
|
|
|
* (via yyrestart()), so that the user can continue scanning by
|
|
|
|
* just pointing yyin at a new input file.
|
2005-08-28 02:50:39 +08:00
|
|
|
*/
|
|
|
|
#define YY_BUFFER_EOF_PENDING 2
|
|
|
|
};
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
static YY_BUFFER_STATE yy_current_buffer = 0;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* We provide macros for accessing buffer states in case in the
|
|
|
|
* future we want to put the buffer states in a more general
|
|
|
|
* "scanner state".
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_CURRENT_BUFFER yy_current_buffer
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* yy_hold_char holds the character lost when yytext is formed. */
|
2005-08-28 02:50:39 +08:00
|
|
|
static char yy_hold_char;
|
2006-10-18 10:21:48 +08:00
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
static int yy_n_chars; /* number of characters read into yy_ch_buf */
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
int yyleng;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* Points to current character in buffer. */
|
|
|
|
static char *yy_c_buf_p = (char *) 0;
|
2006-10-18 10:21:48 +08:00
|
|
|
static int yy_init = 1; /* whether we need to initialize */
|
2005-08-28 02:50:39 +08:00
|
|
|
static int yy_start = 0; /* start state number */
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* Flag which is used to allow yywrap()'s to do buffer switches
|
|
|
|
* instead of setting up a fresh yyin. A bit of a hack ...
|
2005-08-28 02:50:39 +08:00
|
|
|
*/
|
|
|
|
static int yy_did_buffer_switch_on_eof;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
void yyrestart YY_PROTO(( FILE *input_file ));
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
void yy_switch_to_buffer YY_PROTO(( YY_BUFFER_STATE new_buffer ));
|
|
|
|
void yy_load_buffer_state YY_PROTO(( void ));
|
|
|
|
YY_BUFFER_STATE yy_create_buffer YY_PROTO(( FILE *file, int size ));
|
|
|
|
void yy_delete_buffer YY_PROTO(( YY_BUFFER_STATE b ));
|
|
|
|
void yy_init_buffer YY_PROTO(( YY_BUFFER_STATE b, FILE *file ));
|
|
|
|
void yy_flush_buffer YY_PROTO(( YY_BUFFER_STATE b ));
|
|
|
|
#define YY_FLUSH_BUFFER yy_flush_buffer( yy_current_buffer )
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
YY_BUFFER_STATE yy_scan_buffer YY_PROTO(( char *base, yy_size_t size ));
|
|
|
|
YY_BUFFER_STATE yy_scan_string YY_PROTO(( yyconst char *yy_str ));
|
|
|
|
YY_BUFFER_STATE yy_scan_bytes YY_PROTO(( yyconst char *bytes, int len ));
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
static void *yy_flex_alloc YY_PROTO(( yy_size_t ));
|
2006-11-27 09:05:10 +08:00
|
|
|
static inline void *yy_flex_realloc YY_PROTO(( void *, yy_size_t )) YY_MAY_BE_UNUSED;
|
2006-10-18 10:21:48 +08:00
|
|
|
static void yy_flex_free YY_PROTO(( void * ));
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#define yy_new_buffer yy_create_buffer
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
#define yy_set_interactive(is_interactive) \
|
|
|
|
{ \
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_current_buffer ) \
|
|
|
|
yy_current_buffer = yy_create_buffer( yyin, YY_BUF_SIZE ); \
|
|
|
|
yy_current_buffer->yy_is_interactive = is_interactive; \
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#define yy_set_bol(at_bol) \
|
|
|
|
{ \
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_current_buffer ) \
|
|
|
|
yy_current_buffer = yy_create_buffer( yyin, YY_BUF_SIZE ); \
|
|
|
|
yy_current_buffer->yy_at_bol = at_bol; \
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_AT_BOL() (yy_current_buffer->yy_at_bol)
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_USES_REJECT
|
2006-09-15 02:25:26 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#define yywrap() 1
|
|
|
|
#define YY_SKIP_YYWRAP
|
2005-08-28 02:50:39 +08:00
|
|
|
typedef unsigned char YY_CHAR;
|
2006-10-18 10:21:48 +08:00
|
|
|
FILE *yyin = (FILE *) 0, *yyout = (FILE *) 0;
|
2005-08-28 02:50:39 +08:00
|
|
|
typedef int yy_state_type;
|
2006-10-18 10:21:48 +08:00
|
|
|
extern int yylineno;
|
|
|
|
int yylineno = 1;
|
|
|
|
extern char *yytext;
|
|
|
|
#define yytext_ptr yytext
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
static yy_state_type yy_get_previous_state YY_PROTO(( void ));
|
|
|
|
static yy_state_type yy_try_NUL_trans YY_PROTO(( yy_state_type current_state ));
|
|
|
|
static int yy_get_next_buffer YY_PROTO(( void ));
|
|
|
|
static void yy_fatal_error YY_PROTO(( yyconst char msg[] ));
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* Done after the current pattern has been matched and before the
|
2006-10-18 10:21:48 +08:00
|
|
|
* corresponding action - sets up yytext.
|
2005-08-28 02:50:39 +08:00
|
|
|
*/
|
|
|
|
#define YY_DO_BEFORE_ACTION \
|
2006-10-18 10:21:48 +08:00
|
|
|
yytext_ptr = yy_bp; \
|
|
|
|
yyleng = (int) (yy_cp - yy_bp); \
|
|
|
|
yy_hold_char = *yy_cp; \
|
2005-08-28 02:50:39 +08:00
|
|
|
*yy_cp = '\0'; \
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_c_buf_p = yy_cp;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#define YY_NUM_RULES 135
|
|
|
|
#define YY_END_OF_BUFFER 136
|
2007-01-12 15:28:27 +08:00
|
|
|
static yyconst short int yy_acclist[213] =
|
2005-08-28 02:50:39 +08:00
|
|
|
{ 0,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
136, 134, 135, 133, 134, 135, 133, 135, 134, 135,
|
|
|
|
134, 135, 134, 135, 134, 135, 134, 135, 134, 135,
|
|
|
|
126, 134, 135, 126, 134, 135, 1, 134, 135, 134,
|
|
|
|
135, 134, 135, 134, 135, 134, 135, 134, 135, 134,
|
2007-01-12 15:28:27 +08:00
|
|
|
135, 134, 135, 134, 135, 134, 135, 134, 135, 134,
|
|
|
|
135, 134, 135, 134, 135, 134, 135, 134, 135, 134,
|
|
|
|
135, 134, 135, 134, 135, 134, 135, 134, 135, 134,
|
|
|
|
135, 125, 123, 122, 122, 129, 127, 131, 126, 1,
|
|
|
|
108, 39, 68, 53, 69, 64, 23, 125, 122, 122,
|
|
|
|
130, 131, 20, 131, 132, 54, 63, 37, 32, 40,
|
|
|
|
|
|
|
|
3, 56, 78, 83, 81, 82, 80, 79, 84, 88,
|
|
|
|
107, 73, 71, 103, 72, 70, 55, 86, 77, 75,
|
|
|
|
76, 74, 87, 85, 65, 124, 131, 131, 105, 47,
|
|
|
|
89, 67, 59, 115, 62, 66, 116, 104, 22, 128,
|
|
|
|
58, 92, 61, 24, 4, 51, 57, 60, 46, 12,
|
|
|
|
91, 131, 34, 2, 5, 48, 94, 50, 117, 90,
|
|
|
|
21, 114, 43, 7, 49, 28, 42, 98, 97, 8,
|
|
|
|
110, 31, 113, 36, 52, 102, 96, 109, 25, 26,
|
|
|
|
95, 111, 106, 101, 41, 6, 27, 93, 35, 9,
|
|
|
|
17, 10, 99, 11, 100, 33, 13, 15, 14, 30,
|
|
|
|
|
|
|
|
38, 16, 29, 112, 118, 120, 121, 44, 119, 18,
|
|
|
|
45, 19
|
2006-10-18 10:21:48 +08:00
|
|
|
} ;
|
2006-09-18 04:25:45 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static yyconst short int yy_accept[552] =
|
2006-10-18 10:21:48 +08:00
|
|
|
{ 0,
|
|
|
|
1, 1, 1, 2, 4, 7, 9, 11, 13, 15,
|
|
|
|
17, 19, 21, 24, 27, 30, 32, 34, 36, 38,
|
2007-01-12 15:28:27 +08:00
|
|
|
40, 42, 44, 46, 48, 50, 52, 54, 56, 58,
|
|
|
|
60, 62, 64, 66, 68, 70, 72, 72, 73, 73,
|
|
|
|
74, 75, 76, 77, 77, 78, 78, 79, 80, 80,
|
|
|
|
81, 81, 81, 81, 81, 81, 81, 81, 81, 82,
|
|
|
|
82, 83, 83, 83, 83, 83, 83, 83, 83, 84,
|
|
|
|
84, 84, 84, 84, 84, 84, 84, 84, 84, 85,
|
|
|
|
85, 85, 85, 85, 85, 85, 85, 85, 85, 85,
|
|
|
|
86, 86, 86, 86, 86, 86, 86, 87, 87, 87,
|
|
|
|
|
|
|
|
87, 87, 87, 87, 87, 87, 87, 87, 87, 87,
|
|
|
|
87, 87, 87, 87, 88, 88, 88, 88, 88, 88,
|
2006-12-31 13:40:51 +08:00
|
|
|
88, 88, 88, 88, 88, 88, 88, 88, 88, 88,
|
2007-01-12 15:28:27 +08:00
|
|
|
89, 90, 92, 93, 94, 95, 95, 96, 97, 97,
|
|
|
|
97, 98, 98, 98, 99, 99, 100, 100, 100, 100,
|
|
|
|
101, 101, 101, 101, 101, 101, 101, 101, 101, 101,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
102, 102, 102, 102, 102, 102, 102, 102, 102, 102,
|
2007-01-12 15:28:27 +08:00
|
|
|
102, 102, 102, 102, 102, 102, 102, 102, 102, 102,
|
|
|
|
102, 102, 102, 102, 103, 103, 104, 105, 106, 107,
|
|
|
|
108, 109, 109, 110, 111, 111, 111, 112, 112, 112,
|
|
|
|
|
|
|
|
112, 112, 112, 113, 114, 115, 115, 115, 115, 116,
|
|
|
|
117, 117, 117, 118, 118, 118, 118, 118, 118, 118,
|
|
|
|
118, 119, 120, 121, 121, 122, 123, 123, 124, 125,
|
|
|
|
125, 125, 125, 125, 125, 125, 125, 125, 126, 126,
|
|
|
|
126, 127, 128, 128, 128, 128, 129, 129, 129, 129,
|
|
|
|
130, 130, 130, 131, 132, 132, 132, 132, 132, 132,
|
|
|
|
132, 132, 132, 132, 132, 132, 132, 132, 132, 132,
|
|
|
|
133, 134, 134, 134, 134, 134, 135, 136, 136, 136,
|
|
|
|
137, 137, 137, 137, 137, 137, 137, 137, 137, 138,
|
|
|
|
139, 139, 139, 140, 140, 140, 140, 141, 142, 142,
|
|
|
|
|
|
|
|
142, 143, 143, 143, 143, 144, 144, 144, 145, 145,
|
|
|
|
145, 146, 146, 147, 148, 148, 148, 148, 148, 149,
|
|
|
|
149, 150, 150, 151, 151, 151, 152, 153, 154, 154,
|
|
|
|
154, 155, 155, 155, 155, 155, 155, 155, 155, 155,
|
|
|
|
155, 155, 155, 155, 155, 155, 156, 156, 157, 158,
|
|
|
|
158, 158, 158, 158, 158, 158, 158, 158, 158, 158,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
159, 159, 159, 159, 159, 159, 159, 159, 159, 159,
|
2007-01-12 15:28:27 +08:00
|
|
|
159, 159, 159, 160, 160, 160, 160, 161, 161, 162,
|
|
|
|
162, 162, 162, 162, 162, 162, 162, 163, 163, 163,
|
|
|
|
164, 164, 164, 164, 164, 165, 165, 165, 165, 166,
|
|
|
|
|
|
|
|
167, 167, 167, 168, 169, 170, 170, 170, 171, 171,
|
|
|
|
171, 171, 171, 172, 172, 173, 174, 175, 176, 176,
|
|
|
|
176, 176, 177, 177, 177, 178, 179, 180, 181, 182,
|
|
|
|
182, 183, 184, 184, 184, 184, 184, 184, 185, 185,
|
|
|
|
186, 186, 187, 188, 188, 188, 188, 188, 188, 189,
|
|
|
|
189, 189, 189, 189, 189, 189, 189, 189, 190, 190,
|
|
|
|
190, 190, 190, 190, 190, 190, 190, 191, 191, 191,
|
|
|
|
191, 191, 192, 192, 192, 192, 192, 193, 194, 195,
|
|
|
|
195, 196, 196, 196, 196, 197, 197, 197, 197, 198,
|
|
|
|
198, 199, 200, 200, 200, 200, 200, 200, 200, 200,
|
|
|
|
|
|
|
|
200, 200, 200, 200, 200, 201, 201, 201, 201, 201,
|
|
|
|
201, 201, 201, 202, 202, 202, 202, 202, 203, 203,
|
|
|
|
203, 203, 203, 204, 204, 205, 205, 205, 205, 205,
|
|
|
|
205, 205, 205, 205, 205, 205, 205, 205, 206, 206,
|
|
|
|
207, 208, 208, 209, 209, 210, 211, 212, 212, 213,
|
|
|
|
213
|
2005-08-28 02:50:39 +08:00
|
|
|
} ;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
static yyconst int yy_ec[256] =
|
2005-08-28 02:50:39 +08:00
|
|
|
{ 0,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 2, 3,
|
|
|
|
1, 1, 2, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 2, 1, 4, 1, 5, 6, 1, 1, 1,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
1, 1, 7, 1, 8, 9, 1, 10, 11, 11,
|
|
|
|
11, 11, 11, 12, 11, 13, 11, 14, 15, 1,
|
|
|
|
1, 1, 1, 1, 16, 16, 16, 16, 17, 16,
|
2005-08-28 02:50:39 +08:00
|
|
|
5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
|
|
|
|
5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
1, 1, 1, 1, 18, 1, 19, 20, 21, 22,
|
2005-08-28 02:50:39 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
23, 24, 25, 26, 27, 5, 28, 29, 30, 31,
|
|
|
|
32, 33, 34, 35, 36, 37, 38, 39, 40, 41,
|
|
|
|
42, 43, 1, 1, 1, 1, 1, 1, 1, 1,
|
2005-08-28 02:50:39 +08:00
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1
|
|
|
|
} ;
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static yyconst int yy_meta[44] =
|
2005-08-28 02:50:39 +08:00
|
|
|
{ 0,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
1, 1, 2, 1, 3, 1, 1, 3, 3, 3,
|
|
|
|
3, 3, 3, 4, 1, 3, 3, 3, 3, 3,
|
|
|
|
3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
|
2005-08-28 02:50:39 +08:00
|
|
|
3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
3, 3, 3
|
2005-08-28 02:50:39 +08:00
|
|
|
} ;
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static yyconst short int yy_base[556] =
|
2005-08-28 02:50:39 +08:00
|
|
|
{ 0,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
0, 0, 1195, 1196, 1196, 1196, 1190, 1179, 36, 40,
|
|
|
|
44, 50, 56, 62, 0, 63, 66, 81, 89, 47,
|
|
|
|
108, 91, 134, 92, 72, 93, 152, 124, 109, 178,
|
|
|
|
138, 209, 121, 111, 146, 119, 1188, 1196, 1177, 1196,
|
|
|
|
0, 183, 198, 215, 236, 70, 241, 256, 261, 0,
|
|
|
|
68, 122, 140, 125, 160, 101, 154, 31, 1176, 153,
|
|
|
|
155, 183, 48, 184, 265, 170, 192, 149, 1175, 206,
|
|
|
|
227, 203, 175, 225, 273, 274, 223, 262, 269, 277,
|
|
|
|
228, 278, 215, 281, 287, 279, 290, 289, 294, 1174,
|
|
|
|
295, 288, 302, 306, 307, 312, 313, 314, 318, 299,
|
|
|
|
|
|
|
|
319, 46, 322, 323, 324, 328, 326, 332, 336, 339,
|
|
|
|
340, 348, 351, 1173, 353, 337, 354, 358, 359, 360,
|
|
|
|
362, 379, 365, 369, 376, 370, 386, 380, 381, 1172,
|
|
|
|
0, 396, 413, 1171, 427, 444, 0, 1170, 396, 399,
|
|
|
|
1169, 404, 398, 1168, 390, 1167, 414, 418, 420, 1166,
|
|
|
|
431, 406, 445, 429, 432, 446, 448, 449, 450, 451,
|
|
|
|
452, 453, 455, 344, 457, 460, 466, 467, 468, 470,
|
|
|
|
474, 471, 472, 483, 486, 476, 489, 491, 481, 499,
|
|
|
|
496, 497, 500, 1165, 501, 1164, 1163, 1162, 1161, 1160,
|
|
|
|
1159, 502, 1158, 1157, 503, 506, 1156, 534, 510, 511,
|
|
|
|
|
|
|
|
514, 515, 1155, 1154, 1153, 508, 519, 527, 1152, 1151,
|
|
|
|
546, 526, 1150, 525, 549, 550, 551, 554, 556, 552,
|
|
|
|
1149, 1148, 1147, 555, 1146, 1145, 557, 1144, 1143, 558,
|
|
|
|
559, 553, 574, 513, 575, 568, 581, 1142, 560, 576,
|
|
|
|
1196, 591, 599, 605, 609, 614, 615, 584, 616, 1141,
|
|
|
|
617, 618, 1140, 1139, 619, 620, 621, 622, 624, 625,
|
|
|
|
627, 628, 630, 635, 631, 638, 647, 639, 649, 1138,
|
|
|
|
1137, 641, 645, 651, 653, 1136, 1135, 654, 657, 1134,
|
|
|
|
658, 660, 661, 665, 666, 663, 670, 671, 1133, 1132,
|
|
|
|
672, 674, 1131, 676, 679, 685, 0, 1130, 684, 687,
|
|
|
|
|
|
|
|
1129, 691, 695, 696, 1128, 698, 692, 1127, 705, 693,
|
|
|
|
1126, 709, 1125, 1124, 710, 711, 712, 713, 1123, 715,
|
|
|
|
1122, 718, 1121, 722, 724, 1120, 729, 1119, 729, 723,
|
|
|
|
1118, 733, 735, 738, 739, 740, 747, 748, 750, 751,
|
|
|
|
752, 749, 759, 760, 754, 1117, 762, 1116, 1115, 753,
|
|
|
|
765, 763, 764, 767, 772, 774, 775, 779, 781, 1114,
|
|
|
|
783, 784, 787, 786, 796, 799, 789, 785, 791, 801,
|
|
|
|
807, 804, 1113, 806, 809, 810, 1112, 811, 1111, 813,
|
|
|
|
821, 815, 812, 822, 824, 828, 1110, 831, 833, 1109,
|
|
|
|
834, 835, 836, 837, 1108, 838, 839, 840, 1107, 1106,
|
|
|
|
|
|
|
|
848, 843, 1105, 1104, 1103, 854, 849, 1102, 841, 859,
|
|
|
|
862, 855, 1101, 863, 1100, 1099, 1098, 1097, 869, 871,
|
|
|
|
872, 1096, 873, 874, 1095, 1094, 1093, 1092, 1091, 875,
|
|
|
|
1090, 1089, 876, 877, 885, 879, 880, 1088, 881, 1087,
|
|
|
|
883, 1086, 1085, 886, 894, 895, 896, 900, 1084, 903,
|
|
|
|
902, 898, 905, 906, 908, 910, 914, 1083, 916, 922,
|
|
|
|
918, 924, 925, 928, 926, 929, 1080, 930, 934, 936,
|
|
|
|
938, 1070, 943, 939, 942, 944, 1069, 1068, 1066, 950,
|
|
|
|
1064, 946, 945, 960, 1063, 961, 962, 951, 1062, 969,
|
|
|
|
1061, 1060, 970, 971, 972, 973, 974, 976, 977, 979,
|
|
|
|
|
|
|
|
981, 982, 983, 986, 1058, 985, 988, 989, 993, 994,
|
|
|
|
997, 1000, 1057, 1001, 1007, 1009, 1011, 1055, 1012, 1013,
|
|
|
|
1014, 1015, 1054, 1017, 1053, 1018, 1030, 1025, 1028, 1019,
|
|
|
|
1029, 1020, 1031, 1034, 1039, 1042, 1044, 719, 1048, 586,
|
|
|
|
583, 1049, 469, 1050, 415, 248, 245, 1051, 208, 1196,
|
|
|
|
1086, 1088, 169, 1092, 106
|
2005-08-28 02:50:39 +08:00
|
|
|
} ;
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static yyconst short int yy_def[556] =
|
2005-08-28 02:50:39 +08:00
|
|
|
{ 0,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
550, 1, 550, 550, 550, 550, 551, 552, 553, 550,
|
|
|
|
552, 552, 552, 552, 554, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 551, 550, 552, 550,
|
|
|
|
555, 555, 550, 550, 552, 552, 552, 552, 552, 554,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 23, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 550,
|
|
|
|
555, 555, 550, 552, 552, 552, 49, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 49, 552, 552,
|
|
|
|
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
550, 550, 550, 550, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 198, 552, 552, 552,
|
|
|
|
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 550, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 552,
|
|
|
|
552, 552, 552, 552, 552, 552, 552, 552, 552, 0,
|
|
|
|
550, 550, 550, 550, 550
|
2005-08-28 02:50:39 +08:00
|
|
|
} ;
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static yyconst short int yy_nxt[1240] =
|
2005-08-28 02:50:39 +08:00
|
|
|
{ 0,
|
|
|
|
4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
14, 14, 14, 4, 15, 8, 8, 8, 16, 17,
|
|
|
|
18, 19, 20, 21, 22, 8, 23, 8, 24, 25,
|
|
|
|
26, 27, 28, 8, 29, 30, 31, 32, 33, 34,
|
|
|
|
35, 8, 36, 42, 40, 43, 43, 43, 43, 44,
|
|
|
|
44, 44, 44, 45, 45, 45, 45, 40, 46, 40,
|
|
|
|
40, 40, 148, 40, 47, 48, 48, 48, 48, 40,
|
|
|
|
47, 48, 48, 48, 48, 40, 40, 68, 134, 40,
|
|
|
|
69, 40, 153, 40, 51, 40, 198, 70, 56, 138,
|
|
|
|
87, 52, 57, 53, 40, 54, 49, 58, 55, 60,
|
|
|
|
|
|
|
|
59, 61, 40, 88, 40, 40, 40, 64, 131, 89,
|
|
|
|
83, 65, 62, 77, 40, 90, 63, 66, 84, 78,
|
|
|
|
67, 40, 40, 85, 40, 145, 71, 86, 72, 73,
|
|
|
|
91, 101, 40, 126, 40, 40, 74, 40, 40, 124,
|
|
|
|
75, 129, 76, 79, 79, 79, 79, 40, 139, 98,
|
|
|
|
140, 40, 125, 40, 80, 99, 113, 142, 127, 40,
|
|
|
|
100, 141, 40, 81, 82, 40, 40, 40, 40, 114,
|
|
|
|
160, 41, 115, 40, 92, 150, 93, 128, 146, 116,
|
|
|
|
94, 149, 95, 40, 96, 143, 97, 102, 40, 144,
|
|
|
|
147, 40, 132, 132, 132, 132, 40, 40, 158, 103,
|
|
|
|
|
|
|
|
104, 165, 105, 106, 107, 40, 108, 43, 43, 43,
|
|
|
|
43, 151, 109, 152, 110, 111, 40, 112, 102, 40,
|
|
|
|
154, 40, 40, 133, 44, 44, 44, 44, 40, 159,
|
|
|
|
117, 118, 164, 119, 177, 120, 40, 121, 40, 122,
|
|
|
|
40, 40, 161, 123, 47, 45, 45, 45, 45, 40,
|
|
|
|
135, 135, 135, 135, 40, 162, 166, 136, 40, 170,
|
|
|
|
173, 40, 163, 136, 47, 48, 48, 48, 48, 40,
|
|
|
|
137, 137, 137, 137, 40, 40, 137, 137, 40, 137,
|
|
|
|
137, 137, 137, 137, 137, 155, 40, 40, 156, 39,
|
|
|
|
40, 40, 40, 171, 40, 167, 169, 157, 39, 39,
|
|
|
|
|
|
|
|
40, 40, 40, 40, 181, 180, 172, 40, 40, 168,
|
|
|
|
183, 178, 40, 174, 175, 40, 176, 179, 182, 40,
|
|
|
|
40, 186, 184, 185, 187, 40, 40, 40, 189, 191,
|
|
|
|
192, 40, 40, 196, 193, 40, 40, 40, 188, 40,
|
|
|
|
194, 40, 190, 200, 195, 40, 203, 207, 199, 40,
|
|
|
|
40, 201, 40, 40, 209, 197, 205, 40, 211, 213,
|
|
|
|
204, 40, 208, 202, 40, 206, 40, 40, 210, 219,
|
|
|
|
212, 40, 40, 40, 214, 40, 270, 215, 40, 217,
|
|
|
|
220, 222, 40, 40, 225, 216, 233, 232, 236, 40,
|
|
|
|
218, 221, 40, 40, 40, 223, 224, 237, 226, 40,
|
|
|
|
|
|
|
|
227, 228, 234, 40, 235, 132, 132, 132, 132, 40,
|
|
|
|
229, 40, 40, 230, 238, 239, 251, 40, 231, 40,
|
|
|
|
247, 240, 242, 242, 242, 242, 249, 40, 40, 243,
|
|
|
|
248, 40, 250, 40, 252, 243, 135, 135, 135, 135,
|
|
|
|
40, 256, 40, 136, 40, 40, 253, 258, 254, 136,
|
|
|
|
244, 245, 255, 246, 246, 246, 246, 40, 40, 40,
|
|
|
|
259, 40, 40, 40, 40, 40, 40, 257, 40, 264,
|
|
|
|
40, 262, 260, 40, 266, 263, 261, 265, 272, 40,
|
|
|
|
40, 40, 40, 40, 40, 40, 267, 40, 268, 40,
|
|
|
|
276, 269, 278, 279, 40, 271, 40, 277, 274, 40,
|
|
|
|
|
|
|
|
281, 275, 40, 280, 40, 282, 273, 285, 283, 40,
|
|
|
|
40, 286, 40, 40, 40, 40, 40, 288, 287, 40,
|
|
|
|
289, 40, 284, 40, 40, 291, 40, 40, 40, 293,
|
|
|
|
290, 302, 40, 295, 321, 294, 300, 292, 40, 40,
|
|
|
|
40, 303, 296, 297, 297, 297, 297, 299, 298, 297,
|
|
|
|
297, 301, 297, 297, 297, 297, 297, 297, 304, 40,
|
|
|
|
306, 307, 40, 40, 40, 40, 40, 40, 40, 40,
|
|
|
|
40, 40, 40, 40, 309, 305, 311, 308, 313, 316,
|
|
|
|
317, 40, 319, 310, 312, 318, 315, 40, 40, 40,
|
|
|
|
314, 325, 320, 322, 40, 323, 40, 40, 324, 40,
|
|
|
|
|
|
|
|
242, 242, 242, 242, 329, 244, 244, 243, 327, 327,
|
|
|
|
327, 327, 326, 243, 327, 327, 327, 327, 246, 246,
|
|
|
|
246, 246, 40, 246, 246, 246, 246, 40, 40, 40,
|
|
|
|
40, 40, 40, 40, 40, 40, 332, 40, 40, 333,
|
|
|
|
40, 40, 337, 40, 40, 328, 330, 331, 40, 343,
|
|
|
|
336, 40, 40, 339, 40, 338, 334, 335, 40, 341,
|
|
|
|
40, 346, 40, 342, 40, 345, 40, 40, 340, 347,
|
|
|
|
40, 40, 344, 40, 40, 354, 40, 348, 40, 40,
|
|
|
|
355, 349, 353, 40, 40, 40, 350, 40, 351, 40,
|
|
|
|
352, 360, 40, 359, 356, 357, 358, 40, 40, 362,
|
|
|
|
|
|
|
|
40, 361, 364, 363, 40, 40, 40, 369, 40, 40,
|
|
|
|
368, 40, 374, 365, 370, 366, 367, 371, 40, 372,
|
|
|
|
373, 376, 40, 40, 40, 40, 40, 375, 40, 377,
|
|
|
|
380, 40, 40, 378, 379, 40, 40, 40, 327, 327,
|
|
|
|
327, 327, 40, 381, 388, 384, 40, 387, 40, 382,
|
|
|
|
386, 40, 40, 40, 383, 390, 391, 385, 393, 392,
|
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 389, 396,
|
|
|
|
395, 399, 40, 40, 402, 40, 40, 40, 40, 404,
|
|
|
|
40, 394, 403, 397, 398, 40, 407, 40, 40, 400,
|
|
|
|
401, 405, 40, 406, 40, 408, 40, 40, 40, 40,
|
|
|
|
|
|
|
|
40, 409, 40, 413, 40, 411, 415, 416, 417, 40,
|
|
|
|
410, 412, 40, 414, 40, 420, 421, 40, 418, 40,
|
|
|
|
40, 419, 40, 40, 40, 40, 40, 422, 40, 423,
|
|
|
|
424, 426, 428, 430, 40, 40, 425, 40, 433, 432,
|
|
|
|
434, 40, 431, 429, 40, 427, 40, 40, 40, 40,
|
|
|
|
40, 40, 40, 40, 40, 440, 40, 437, 436, 442,
|
|
|
|
435, 40, 40, 451, 439, 446, 447, 40, 40, 438,
|
|
|
|
444, 445, 40, 443, 449, 40, 40, 441, 450, 448,
|
|
|
|
453, 452, 40, 455, 40, 40, 40, 40, 40, 40,
|
|
|
|
40, 454, 40, 40, 40, 459, 40, 460, 40, 40,
|
|
|
|
|
|
|
|
461, 457, 458, 456, 462, 465, 464, 40, 40, 40,
|
|
|
|
466, 40, 463, 40, 468, 40, 40, 467, 40, 40,
|
|
|
|
469, 40, 473, 40, 472, 474, 476, 40, 470, 40,
|
|
|
|
479, 40, 475, 477, 471, 40, 484, 40, 40, 40,
|
|
|
|
478, 40, 40, 40, 483, 480, 485, 40, 487, 40,
|
|
|
|
481, 40, 40, 489, 482, 40, 40, 40, 40, 40,
|
|
|
|
493, 486, 488, 40, 40, 500, 497, 490, 499, 495,
|
|
|
|
491, 494, 492, 40, 40, 40, 498, 504, 496, 501,
|
|
|
|
503, 502, 40, 40, 40, 40, 40, 40, 506, 40,
|
|
|
|
40, 509, 40, 507, 40, 40, 40, 512, 40, 40,
|
|
|
|
|
|
|
|
515, 40, 40, 510, 517, 505, 40, 40, 508, 514,
|
|
|
|
40, 516, 518, 40, 40, 513, 522, 519, 511, 523,
|
|
|
|
40, 520, 40, 525, 40, 40, 40, 40, 40, 521,
|
|
|
|
40, 40, 40, 40, 529, 526, 524, 527, 40, 528,
|
|
|
|
531, 40, 40, 40, 40, 532, 534, 40, 533, 530,
|
|
|
|
535, 536, 40, 538, 542, 40, 540, 40, 537, 543,
|
|
|
|
539, 40, 40, 40, 40, 541, 40, 40, 40, 547,
|
|
|
|
40, 40, 548, 40, 40, 40, 40, 40, 546, 40,
|
|
|
|
545, 40, 40, 40, 544, 549, 37, 37, 37, 37,
|
|
|
|
39, 39, 50, 40, 50, 50, 40, 40, 40, 40,
|
2006-12-31 13:40:51 +08:00
|
|
|
|
2006-05-20 05:28:53 +08:00
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
|
2006-11-03 04:25:50 +08:00
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
|
2006-05-20 05:28:53 +08:00
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
|
2006-10-22 14:08:13 +08:00
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
|
2006-12-03 13:46:11 +08:00
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
|
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
|
2006-12-23 14:05:41 +08:00
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
|
2006-12-30 04:35:03 +08:00
|
|
|
40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
40, 40, 40, 40, 40, 241, 40, 40, 40, 40,
|
|
|
|
40, 130, 40, 38, 550, 3, 550, 550, 550, 550,
|
|
|
|
|
|
|
|
550, 550, 550, 550, 550, 550, 550, 550, 550, 550,
|
|
|
|
550, 550, 550, 550, 550, 550, 550, 550, 550, 550,
|
|
|
|
550, 550, 550, 550, 550, 550, 550, 550, 550, 550,
|
|
|
|
550, 550, 550, 550, 550, 550, 550, 550, 550
|
2005-08-28 02:50:39 +08:00
|
|
|
} ;
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
static yyconst short int yy_chk[1240] =
|
2005-08-28 02:50:39 +08:00
|
|
|
{ 0,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
|
|
|
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
1, 1, 1, 9, 58, 9, 9, 9, 9, 10,
|
|
|
|
10, 10, 10, 11, 11, 11, 11, 11, 12, 102,
|
|
|
|
20, 63, 58, 12, 13, 13, 13, 13, 13, 13,
|
|
|
|
14, 14, 14, 14, 14, 14, 16, 20, 46, 17,
|
|
|
|
20, 51, 63, 46, 16, 25, 102, 20, 17, 51,
|
|
|
|
25, 16, 17, 16, 18, 16, 13, 17, 16, 18,
|
|
|
|
|
|
|
|
17, 18, 19, 25, 22, 24, 26, 19, 555, 25,
|
|
|
|
24, 19, 18, 22, 56, 26, 18, 19, 24, 22,
|
|
|
|
19, 21, 29, 24, 34, 56, 21, 24, 21, 21,
|
|
|
|
26, 29, 36, 34, 33, 52, 21, 28, 54, 33,
|
|
|
|
21, 36, 21, 23, 23, 23, 23, 23, 52, 28,
|
|
|
|
52, 31, 33, 53, 23, 28, 31, 54, 35, 35,
|
|
|
|
28, 53, 68, 23, 23, 27, 60, 57, 61, 31,
|
|
|
|
68, 553, 31, 55, 27, 61, 27, 35, 57, 31,
|
|
|
|
27, 60, 27, 66, 27, 55, 27, 30, 73, 55,
|
|
|
|
57, 30, 42, 42, 42, 42, 62, 64, 66, 30,
|
|
|
|
|
|
|
|
30, 73, 30, 30, 30, 67, 30, 43, 43, 43,
|
|
|
|
43, 62, 30, 62, 30, 30, 72, 30, 32, 70,
|
|
|
|
64, 549, 32, 44, 44, 44, 44, 44, 83, 67,
|
|
|
|
32, 32, 72, 32, 83, 32, 77, 32, 74, 32,
|
|
|
|
71, 81, 70, 32, 45, 45, 45, 45, 45, 45,
|
|
|
|
47, 47, 47, 47, 47, 71, 74, 47, 547, 77,
|
|
|
|
81, 546, 71, 47, 48, 48, 48, 48, 48, 48,
|
|
|
|
49, 49, 49, 49, 49, 78, 49, 49, 65, 49,
|
|
|
|
49, 49, 49, 49, 49, 65, 75, 76, 65, 79,
|
|
|
|
80, 82, 86, 78, 84, 75, 76, 65, 79, 79,
|
|
|
|
|
|
|
|
85, 92, 88, 87, 86, 85, 80, 89, 91, 75,
|
|
|
|
88, 84, 100, 82, 82, 93, 82, 84, 87, 94,
|
|
|
|
95, 92, 89, 91, 93, 96, 97, 98, 94, 95,
|
|
|
|
96, 99, 101, 100, 97, 103, 104, 105, 93, 107,
|
|
|
|
98, 106, 94, 104, 99, 108, 105, 107, 103, 109,
|
|
|
|
116, 104, 110, 111, 108, 101, 106, 164, 109, 111,
|
|
|
|
105, 112, 107, 104, 113, 106, 115, 117, 108, 116,
|
|
|
|
110, 118, 119, 120, 112, 121, 164, 113, 123, 115,
|
|
|
|
117, 119, 124, 126, 121, 113, 124, 123, 126, 125,
|
|
|
|
115, 118, 122, 128, 129, 119, 120, 127, 121, 127,
|
|
|
|
|
|
|
|
122, 122, 125, 145, 125, 132, 132, 132, 132, 139,
|
|
|
|
122, 143, 140, 122, 128, 129, 145, 142, 122, 152,
|
|
|
|
139, 129, 133, 133, 133, 133, 142, 147, 545, 133,
|
|
|
|
140, 148, 143, 149, 147, 133, 135, 135, 135, 135,
|
|
|
|
135, 152, 154, 135, 151, 155, 148, 154, 149, 135,
|
|
|
|
136, 136, 151, 136, 136, 136, 136, 136, 153, 156,
|
|
|
|
155, 157, 158, 159, 160, 161, 162, 153, 163, 159,
|
|
|
|
165, 158, 156, 166, 161, 158, 157, 160, 166, 167,
|
|
|
|
168, 169, 543, 170, 172, 173, 161, 171, 162, 176,
|
|
|
|
169, 163, 170, 171, 179, 165, 174, 169, 168, 175,
|
|
|
|
|
|
|
|
173, 168, 177, 172, 178, 174, 167, 176, 175, 181,
|
|
|
|
182, 177, 180, 183, 185, 192, 195, 179, 178, 196,
|
|
|
|
180, 206, 175, 199, 200, 182, 234, 201, 202, 185,
|
|
|
|
181, 206, 207, 195, 234, 192, 201, 183, 214, 212,
|
|
|
|
208, 207, 196, 198, 198, 198, 198, 200, 199, 198,
|
|
|
|
198, 202, 198, 198, 198, 198, 198, 198, 208, 211,
|
|
|
|
212, 214, 215, 216, 217, 220, 232, 218, 224, 219,
|
|
|
|
227, 230, 231, 239, 216, 211, 218, 215, 219, 227,
|
|
|
|
230, 236, 232, 217, 218, 231, 224, 233, 235, 240,
|
|
|
|
220, 239, 233, 235, 237, 236, 541, 248, 237, 540,
|
|
|
|
|
|
|
|
242, 242, 242, 242, 248, 243, 243, 242, 243, 243,
|
|
|
|
243, 243, 240, 242, 244, 244, 244, 244, 245, 245,
|
|
|
|
245, 245, 245, 246, 246, 246, 246, 246, 247, 249,
|
|
|
|
251, 252, 255, 256, 257, 258, 252, 259, 260, 255,
|
|
|
|
261, 262, 259, 263, 265, 247, 249, 251, 264, 265,
|
|
|
|
258, 266, 268, 261, 272, 260, 256, 257, 273, 263,
|
|
|
|
267, 268, 269, 264, 274, 267, 275, 278, 262, 269,
|
|
|
|
279, 281, 266, 282, 283, 279, 286, 272, 284, 285,
|
|
|
|
281, 273, 278, 287, 288, 291, 274, 292, 274, 294,
|
|
|
|
275, 286, 295, 285, 282, 283, 284, 299, 296, 288,
|
|
|
|
|
|
|
|
300, 287, 292, 291, 302, 307, 310, 300, 303, 304,
|
|
|
|
299, 306, 307, 294, 302, 295, 296, 303, 309, 304,
|
|
|
|
306, 310, 312, 315, 316, 317, 318, 309, 320, 312,
|
|
|
|
317, 322, 538, 315, 316, 324, 330, 325, 327, 327,
|
|
|
|
327, 327, 329, 318, 330, 324, 332, 329, 333, 320,
|
|
|
|
325, 334, 335, 336, 322, 333, 334, 324, 336, 335,
|
|
|
|
337, 338, 342, 339, 340, 341, 350, 345, 332, 339,
|
|
|
|
338, 342, 343, 344, 345, 347, 352, 353, 351, 350,
|
|
|
|
354, 337, 347, 340, 341, 355, 353, 356, 357, 343,
|
|
|
|
344, 351, 358, 352, 359, 354, 361, 362, 368, 364,
|
|
|
|
|
|
|
|
363, 355, 367, 359, 369, 357, 362, 363, 364, 365,
|
|
|
|
356, 358, 366, 361, 370, 367, 368, 372, 365, 374,
|
|
|
|
371, 366, 375, 376, 378, 383, 380, 369, 382, 370,
|
|
|
|
371, 374, 376, 380, 381, 384, 372, 385, 383, 382,
|
|
|
|
384, 386, 381, 378, 388, 375, 389, 391, 392, 393,
|
|
|
|
394, 396, 397, 398, 409, 392, 402, 388, 386, 394,
|
|
|
|
385, 401, 407, 409, 391, 401, 401, 406, 412, 389,
|
|
|
|
397, 398, 410, 396, 406, 411, 414, 393, 407, 402,
|
|
|
|
411, 410, 419, 414, 420, 421, 423, 424, 430, 433,
|
|
|
|
434, 412, 436, 437, 439, 423, 441, 424, 435, 444,
|
|
|
|
|
|
|
|
430, 420, 421, 419, 433, 436, 435, 445, 446, 447,
|
|
|
|
437, 452, 434, 448, 441, 451, 450, 439, 453, 454,
|
|
|
|
444, 455, 448, 456, 447, 450, 452, 457, 445, 459,
|
|
|
|
455, 461, 451, 453, 446, 460, 461, 462, 463, 465,
|
|
|
|
454, 464, 466, 468, 460, 456, 462, 469, 464, 470,
|
|
|
|
457, 471, 474, 466, 459, 475, 473, 476, 483, 482,
|
|
|
|
471, 463, 465, 480, 488, 483, 476, 468, 482, 474,
|
|
|
|
469, 473, 470, 484, 486, 487, 480, 488, 475, 484,
|
|
|
|
487, 486, 490, 493, 494, 495, 496, 497, 493, 498,
|
|
|
|
499, 496, 500, 494, 501, 502, 503, 499, 506, 504,
|
|
|
|
|
|
|
|
502, 507, 508, 497, 504, 490, 509, 510, 495, 501,
|
|
|
|
511, 503, 506, 512, 514, 500, 510, 507, 498, 511,
|
|
|
|
515, 508, 516, 514, 517, 519, 520, 521, 522, 509,
|
|
|
|
524, 526, 530, 532, 519, 515, 512, 516, 528, 517,
|
|
|
|
521, 529, 531, 527, 533, 522, 526, 534, 524, 520,
|
|
|
|
527, 528, 535, 530, 534, 536, 532, 537, 529, 535,
|
|
|
|
531, 539, 542, 544, 548, 533, 525, 523, 518, 542,
|
|
|
|
513, 505, 544, 492, 491, 489, 485, 481, 539, 479,
|
|
|
|
537, 478, 477, 472, 536, 548, 551, 551, 551, 551,
|
|
|
|
552, 552, 554, 467, 554, 554, 458, 449, 443, 442,
|
|
|
|
|
|
|
|
440, 438, 432, 431, 429, 428, 427, 426, 425, 422,
|
|
|
|
418, 417, 416, 415, 413, 408, 405, 404, 403, 400,
|
|
|
|
399, 395, 390, 387, 379, 377, 373, 360, 349, 348,
|
|
|
|
346, 331, 328, 326, 323, 321, 319, 314, 313, 311,
|
|
|
|
308, 305, 301, 298, 293, 290, 289, 280, 277, 276,
|
|
|
|
271, 270, 254, 253, 250, 238, 229, 228, 226, 225,
|
|
|
|
223, 222, 221, 213, 210, 209, 205, 204, 203, 197,
|
|
|
|
194, 193, 191, 190, 189, 188, 187, 186, 184, 150,
|
|
|
|
146, 144, 141, 138, 134, 130, 114, 90, 69, 59,
|
|
|
|
39, 37, 8, 7, 3, 550, 550, 550, 550, 550,
|
|
|
|
|
|
|
|
550, 550, 550, 550, 550, 550, 550, 550, 550, 550,
|
|
|
|
550, 550, 550, 550, 550, 550, 550, 550, 550, 550,
|
|
|
|
550, 550, 550, 550, 550, 550, 550, 550, 550, 550,
|
|
|
|
550, 550, 550, 550, 550, 550, 550, 550, 550
|
2005-08-28 02:50:39 +08:00
|
|
|
} ;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
static yy_state_type yy_state_buf[YY_BUF_SIZE + 2], *yy_state_ptr;
|
|
|
|
static char *yy_full_match;
|
|
|
|
static int yy_lp;
|
|
|
|
#define REJECT \
|
|
|
|
{ \
|
|
|
|
*yy_cp = yy_hold_char; /* undo effects of setting up yytext */ \
|
|
|
|
yy_cp = yy_full_match; /* restore poss. backed-over text */ \
|
|
|
|
++yy_lp; \
|
|
|
|
goto find_rule; \
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
#define yymore() yymore_used_but_not_detected
|
|
|
|
#define YY_MORE_ADJ 0
|
|
|
|
#define YY_RESTORE_YY_MORE_OFFSET
|
2006-10-18 10:21:48 +08:00
|
|
|
char *yytext;
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 1 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-10-18 10:21:48 +08:00
|
|
|
#define INITIAL 0
|
2005-08-28 02:50:39 +08:00
|
|
|
/*===-- Lexer.l - Scanner for llvm assembly files --------------*- C++ -*--===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file was developed by the LLVM research group and is distributed under
|
|
|
|
// the University of Illinois Open Source License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the flex scanner for LLVM assembly languages files.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===*/
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_NEVER_INTERACTIVE 1
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 28 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
#include "ParserInternals.h"
|
|
|
|
#include "llvm/Module.h"
|
|
|
|
#include <list>
|
|
|
|
#include "llvmAsmParser.h"
|
|
|
|
#include <cctype>
|
|
|
|
#include <cstdlib>
|
|
|
|
|
|
|
|
void set_scan_file(FILE * F){
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_switch_to_buffer(yy_create_buffer( F, YY_BUF_SIZE ) );
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
void set_scan_string (const char * str) {
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_scan_string (str);
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
2006-11-03 04:25:50 +08:00
|
|
|
// Construct a token value for a non-obsolete token
|
2005-08-28 02:50:39 +08:00
|
|
|
#define RET_TOK(type, Enum, sym) \
|
2006-12-03 13:46:11 +08:00
|
|
|
llvmAsmlval.type = Instruction::Enum; \
|
2006-11-03 04:25:50 +08:00
|
|
|
return sym
|
|
|
|
|
2006-11-27 09:05:10 +08:00
|
|
|
// Construct a token value for an obsolete token
|
2006-12-03 13:46:11 +08:00
|
|
|
#define RET_TY(CTYPE, SYM) \
|
|
|
|
llvmAsmlval.PrimType = CTYPE;\
|
2006-12-01 08:33:46 +08:00
|
|
|
return SYM
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
// TODO: All of the static identifiers are figured out by the lexer,
|
|
|
|
// these should be hashed to reduce the lexer size
|
|
|
|
|
|
|
|
|
|
|
|
// atoull - Convert an ascii string of decimal digits into the unsigned long
|
|
|
|
// long representation... this does not have to do input error checking,
|
|
|
|
// because we know that the input will be matched by a suitable regex...
|
|
|
|
//
|
|
|
|
static uint64_t atoull(const char *Buffer) {
|
|
|
|
uint64_t Result = 0;
|
|
|
|
for (; *Buffer; Buffer++) {
|
|
|
|
uint64_t OldRes = Result;
|
|
|
|
Result *= 10;
|
|
|
|
Result += *Buffer-'0';
|
|
|
|
if (Result < OldRes) // Uh, oh, overflow detected!!!
|
2006-08-18 16:43:06 +08:00
|
|
|
GenerateError("constant bigger than 64 bits detected!");
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
static uint64_t HexIntToVal(const char *Buffer) {
|
|
|
|
uint64_t Result = 0;
|
|
|
|
for (; *Buffer; ++Buffer) {
|
|
|
|
uint64_t OldRes = Result;
|
|
|
|
Result *= 16;
|
|
|
|
char C = *Buffer;
|
|
|
|
if (C >= '0' && C <= '9')
|
|
|
|
Result += C-'0';
|
|
|
|
else if (C >= 'A' && C <= 'F')
|
|
|
|
Result += C-'A'+10;
|
|
|
|
else if (C >= 'a' && C <= 'f')
|
|
|
|
Result += C-'a'+10;
|
|
|
|
|
|
|
|
if (Result < OldRes) // Uh, oh, overflow detected!!!
|
2006-08-18 16:43:06 +08:00
|
|
|
GenerateError("constant bigger than 64 bits detected!");
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// HexToFP - Convert the ascii string in hexidecimal format to the floating
|
|
|
|
// point representation of it.
|
|
|
|
//
|
|
|
|
static double HexToFP(const char *Buffer) {
|
|
|
|
// Behave nicely in the face of C TBAA rules... see:
|
|
|
|
// http://www.nullstone.com/htmls/category/aliastyp.htm
|
|
|
|
union {
|
|
|
|
uint64_t UI;
|
|
|
|
double FP;
|
|
|
|
} UIntToFP;
|
|
|
|
UIntToFP.UI = HexIntToVal(Buffer);
|
|
|
|
|
|
|
|
assert(sizeof(double) == sizeof(uint64_t) &&
|
|
|
|
"Data sizes incompatible on this target!");
|
|
|
|
return UIntToFP.FP; // Cast Hex constant to double
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// UnEscapeLexed - Run through the specified buffer and change \xx codes to the
|
|
|
|
// appropriate character. If AllowNull is set to false, a \00 value will cause
|
|
|
|
// an exception to be thrown.
|
|
|
|
//
|
|
|
|
// If AllowNull is set to true, the return value of the function points to the
|
|
|
|
// last character of the string in memory.
|
|
|
|
//
|
|
|
|
char *UnEscapeLexed(char *Buffer, bool AllowNull) {
|
|
|
|
char *BOut = Buffer;
|
|
|
|
for (char *BIn = Buffer; *BIn; ) {
|
|
|
|
if (BIn[0] == '\\' && isxdigit(BIn[1]) && isxdigit(BIn[2])) {
|
|
|
|
char Tmp = BIn[3]; BIn[3] = 0; // Terminate string
|
|
|
|
*BOut = (char)strtol(BIn+1, 0, 16); // Convert to number
|
|
|
|
if (!AllowNull && !*BOut)
|
2006-08-18 16:43:06 +08:00
|
|
|
GenerateError("String literal cannot accept \\00 escape!");
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
BIn[3] = Tmp; // Restore character
|
|
|
|
BIn += 3; // Skip over handled chars
|
|
|
|
++BOut;
|
|
|
|
} else {
|
|
|
|
*BOut++ = *BIn++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return BOut;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // End llvm namespace
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define YY_NEVER_INTERACTIVE 1
|
|
|
|
/* Comments start with a ; and go till end of line */
|
|
|
|
/* Variable(Value) identifiers start with a % sign */
|
|
|
|
/* Label identifiers end with a colon */
|
|
|
|
/* Quoted names can contain any character except " and \ */
|
|
|
|
/* [PN]Integer: match positive and negative literal integer values that
|
|
|
|
* are preceeded by a '%' character. These represent unnamed variable slots.
|
|
|
|
*/
|
|
|
|
/* E[PN]Integer: match positive and negative literal integer values */
|
|
|
|
/* FPConstant - A Floating point constant.
|
|
|
|
*/
|
|
|
|
/* HexFPConstant - Floating point constant represented in IEEE format as a
|
|
|
|
* hexadecimal number for when exponential notation is not precise enough.
|
|
|
|
*/
|
|
|
|
/* HexIntConstant - Hexadecimal constant generated by the CFE to avoid forcing
|
|
|
|
* it to deal with 64 bit numbers.
|
|
|
|
*/
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 1029 "Lexer.cpp"
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* Macros after this point can all be overridden by user definitions in
|
|
|
|
* section 1.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef YY_SKIP_YYWRAP
|
|
|
|
#ifdef __cplusplus
|
2006-10-18 10:21:48 +08:00
|
|
|
extern "C" int yywrap YY_PROTO(( void ));
|
2005-08-28 02:50:39 +08:00
|
|
|
#else
|
2006-10-18 10:21:48 +08:00
|
|
|
extern int yywrap YY_PROTO(( void ));
|
|
|
|
#endif
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
#ifndef YY_NO_UNPUT
|
|
|
|
static inline void yyunput YY_PROTO(( int c, char *buf_ptr ));
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef yytext_ptr
|
2006-10-18 10:21:48 +08:00
|
|
|
static void yy_flex_strncpy YY_PROTO(( char *, yyconst char *, int ));
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef YY_NEED_STRLEN
|
2006-10-18 10:21:48 +08:00
|
|
|
static int yy_flex_strlen YY_PROTO(( yyconst char * ));
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef YY_NO_INPUT
|
2006-09-15 02:25:26 +08:00
|
|
|
#ifdef __cplusplus
|
2006-10-18 10:21:48 +08:00
|
|
|
static int yyinput YY_PROTO(( void ));
|
|
|
|
#else
|
|
|
|
static int input YY_PROTO(( void ));
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if YY_STACK_USED
|
|
|
|
static int yy_start_stack_ptr = 0;
|
|
|
|
static int yy_start_stack_depth = 0;
|
|
|
|
static int *yy_start_stack = 0;
|
|
|
|
#ifndef YY_NO_PUSH_STATE
|
|
|
|
static void yy_push_state YY_PROTO(( int new_state ));
|
|
|
|
#endif
|
|
|
|
#ifndef YY_NO_POP_STATE
|
|
|
|
static void yy_pop_state YY_PROTO(( void ));
|
|
|
|
#endif
|
|
|
|
#ifndef YY_NO_TOP_STATE
|
|
|
|
static int yy_top_state YY_PROTO(( void ));
|
|
|
|
#endif
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
#else
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_NO_PUSH_STATE 1
|
|
|
|
#define YY_NO_POP_STATE 1
|
|
|
|
#define YY_NO_TOP_STATE 1
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_MALLOC_DECL
|
|
|
|
YY_MALLOC_DECL
|
|
|
|
#else
|
|
|
|
#if __STDC__
|
|
|
|
#ifndef __cplusplus
|
|
|
|
#include <stdlib.h>
|
|
|
|
#endif
|
|
|
|
#else
|
|
|
|
/* Just try to get by without declaring the routines. This will fail
|
|
|
|
* miserably on non-ANSI systems for which sizeof(size_t) != sizeof(int)
|
|
|
|
* or sizeof(void*) != sizeof(int).
|
|
|
|
*/
|
|
|
|
#endif
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Amount of stuff to slurp up with each read. */
|
|
|
|
#ifndef YY_READ_BUF_SIZE
|
|
|
|
#define YY_READ_BUF_SIZE 8192
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Copy whatever the last rule matched to the standard output. */
|
2006-10-18 10:21:48 +08:00
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
#ifndef ECHO
|
|
|
|
/* This used to be an fputs(), but since the string might contain NUL's,
|
|
|
|
* we now use fwrite().
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
#define ECHO (void) fwrite( yytext, yyleng, 1, yyout )
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Gets input and stuffs it into "buf". number of characters read, or YY_NULL,
|
|
|
|
* is returned in "result".
|
|
|
|
*/
|
|
|
|
#ifndef YY_INPUT
|
|
|
|
#define YY_INPUT(buf,result,max_size) \
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_current_buffer->yy_is_interactive ) \
|
2005-08-28 02:50:39 +08:00
|
|
|
{ \
|
2006-10-18 10:21:48 +08:00
|
|
|
int c = '*', n; \
|
2005-08-28 02:50:39 +08:00
|
|
|
for ( n = 0; n < max_size && \
|
2006-10-18 10:21:48 +08:00
|
|
|
(c = getc( yyin )) != EOF && c != '\n'; ++n ) \
|
2005-08-28 02:50:39 +08:00
|
|
|
buf[n] = (char) c; \
|
|
|
|
if ( c == '\n' ) \
|
|
|
|
buf[n++] = (char) c; \
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( c == EOF && ferror( yyin ) ) \
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_FATAL_ERROR( "input in flex scanner failed" ); \
|
|
|
|
result = n; \
|
|
|
|
} \
|
2006-10-18 10:21:48 +08:00
|
|
|
else if ( ((result = fread( buf, 1, max_size, yyin )) == 0) \
|
|
|
|
&& ferror( yyin ) ) \
|
|
|
|
YY_FATAL_ERROR( "input in flex scanner failed" );
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/* No semi-colon after return; correct usage is to write "yyterminate();" -
|
|
|
|
* we don't want an extra ';' after the "return" because that will cause
|
|
|
|
* some compilers to complain about unreachable statements.
|
|
|
|
*/
|
|
|
|
#ifndef yyterminate
|
|
|
|
#define yyterminate() return YY_NULL
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Number of entries by which start-condition stack grows. */
|
|
|
|
#ifndef YY_START_STACK_INCR
|
|
|
|
#define YY_START_STACK_INCR 25
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Report a fatal error. */
|
|
|
|
#ifndef YY_FATAL_ERROR
|
|
|
|
#define YY_FATAL_ERROR(msg) yy_fatal_error( msg )
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Default declaration of generated scanner - a define so the user can
|
|
|
|
* easily add parameters.
|
|
|
|
*/
|
|
|
|
#ifndef YY_DECL
|
2006-10-18 10:21:48 +08:00
|
|
|
#define YY_DECL int yylex YY_PROTO(( void ))
|
|
|
|
#endif
|
2006-09-15 02:25:26 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* Code executed at the beginning of each rule, after yytext and yyleng
|
2005-08-28 02:50:39 +08:00
|
|
|
* have been set up.
|
|
|
|
*/
|
|
|
|
#ifndef YY_USER_ACTION
|
|
|
|
#define YY_USER_ACTION
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Code executed at the end of each rule. */
|
|
|
|
#ifndef YY_BREAK
|
|
|
|
#define YY_BREAK break;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#define YY_RULE_SETUP \
|
|
|
|
YY_USER_ACTION
|
|
|
|
|
|
|
|
YY_DECL
|
2006-10-18 10:21:48 +08:00
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
register yy_state_type yy_current_state;
|
2006-11-27 09:05:10 +08:00
|
|
|
register char *yy_cp = NULL, *yy_bp = NULL;
|
2005-08-28 02:50:39 +08:00
|
|
|
register int yy_act;
|
2006-10-18 10:21:48 +08:00
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 188 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 1183 "Lexer.cpp"
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_init )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_init = 0;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
#ifdef YY_USER_INIT
|
|
|
|
YY_USER_INIT;
|
|
|
|
#endif
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_start )
|
|
|
|
yy_start = 1; /* first start state */
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yyin )
|
|
|
|
yyin = stdin;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yyout )
|
|
|
|
yyout = stdout;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_current_buffer )
|
|
|
|
yy_current_buffer =
|
|
|
|
yy_create_buffer( yyin, YY_BUF_SIZE );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_load_buffer_state();
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
while ( 1 ) /* loops until end-of-file is reached */
|
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_cp = yy_c_buf_p;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* Support of yytext. */
|
|
|
|
*yy_cp = yy_hold_char;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* yy_bp points to the position in yy_ch_buf of the start of
|
|
|
|
* the current run.
|
|
|
|
*/
|
|
|
|
yy_bp = yy_cp;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_state = yy_start;
|
|
|
|
yy_state_ptr = yy_state_buf;
|
|
|
|
*yy_state_ptr++ = yy_current_state;
|
2005-08-28 02:50:39 +08:00
|
|
|
yy_match:
|
|
|
|
do
|
|
|
|
{
|
|
|
|
register YY_CHAR yy_c = yy_ec[YY_SC_TO_UI(*yy_cp)];
|
|
|
|
while ( yy_chk[yy_base[yy_current_state] + yy_c] != yy_current_state )
|
|
|
|
{
|
|
|
|
yy_current_state = (int) yy_def[yy_current_state];
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
if ( yy_current_state >= 551 )
|
2005-08-28 02:50:39 +08:00
|
|
|
yy_c = yy_meta[(unsigned int) yy_c];
|
|
|
|
}
|
|
|
|
yy_current_state = yy_nxt[yy_base[yy_current_state] + (unsigned int) yy_c];
|
2006-10-18 10:21:48 +08:00
|
|
|
*yy_state_ptr++ = yy_current_state;
|
2005-08-28 02:50:39 +08:00
|
|
|
++yy_cp;
|
|
|
|
}
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
while ( yy_current_state != 550 );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
yy_find_action:
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_state = *--yy_state_ptr;
|
|
|
|
yy_lp = yy_accept[yy_current_state];
|
2007-01-12 15:28:27 +08:00
|
|
|
find_rule: /* we branch to this label when backing up */
|
2006-10-18 10:21:48 +08:00
|
|
|
for ( ; ; ) /* until we find what rule we matched */
|
|
|
|
{
|
|
|
|
if ( yy_lp && yy_lp < yy_accept[yy_current_state + 1] )
|
|
|
|
{
|
|
|
|
yy_act = yy_acclist[yy_lp];
|
|
|
|
{
|
|
|
|
yy_full_match = yy_cp;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--yy_cp;
|
|
|
|
yy_current_state = *--yy_state_ptr;
|
|
|
|
yy_lp = yy_accept[yy_current_state];
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
YY_DO_BEFORE_ACTION;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_act != YY_END_OF_BUFFER )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
int yyl;
|
2006-10-18 10:21:48 +08:00
|
|
|
for ( yyl = 0; yyl < yyleng; ++yyl )
|
|
|
|
if ( yytext[yyl] == '\n' )
|
|
|
|
++yylineno;
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
do_action: /* This label is used only to access EOF actions. */
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
switch ( yy_act )
|
|
|
|
{ /* beginning of action switch */
|
|
|
|
case 1:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 190 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{ /* Ignore comments for now */ }
|
|
|
|
YY_BREAK
|
|
|
|
case 2:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 192 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{ return BEGINTOK; }
|
|
|
|
YY_BREAK
|
|
|
|
case 3:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 193 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{ return ENDTOK; }
|
|
|
|
YY_BREAK
|
|
|
|
case 4:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 194 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{ return TRUETOK; }
|
|
|
|
YY_BREAK
|
|
|
|
case 5:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 195 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{ return FALSETOK; }
|
|
|
|
YY_BREAK
|
|
|
|
case 6:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 196 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{ return DECLARE; }
|
|
|
|
YY_BREAK
|
|
|
|
case 7:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 197 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return DEFINE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 8:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 198 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return GLOBAL; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 9:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 199 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return CONSTANT; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 10:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 200 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return INTERNAL; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 11:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 201 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return LINKONCE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 12:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 202 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return WEAK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 13:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 203 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return APPENDING; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 14:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 204 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return DLLIMPORT; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 15:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 205 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return DLLEXPORT; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 16:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 206 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return EXTERN_WEAK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 17:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 207 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return EXTERNAL; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 18:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 208 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return IMPLEMENTATION; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 19:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 209 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return ZEROINITIALIZER; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 20:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 210 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return DOTDOTDOT; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 21:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 211 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return UNDEF; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 22:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 212 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return NULL_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 23:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 213 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return TO; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 24:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 214 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return TAIL; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 25:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 215 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return TARGET; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 26:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 216 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return TRIPLE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 27:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 217 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return DEPLIBS; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 28:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 218 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return ENDIAN; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 29:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 219 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return POINTERSIZE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 30:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 220 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return DATALAYOUT; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 31:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 221 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return LITTLE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 32:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 222 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return BIG; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 33:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 223 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return VOLATILE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 34:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 224 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return ALIGN; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 35:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 225 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return SECTION; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 36:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 226 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return MODULE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 37:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 227 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return ASM_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 38:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 228 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return SIDEEFFECT; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 39:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 230 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return CC_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 40:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 231 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return CCC_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 41:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 232 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return CSRETCC_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 42:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 233 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return FASTCC_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 43:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 234 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return COLDCC_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 44:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 235 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return X86_STDCALLCC_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 45:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 236 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return X86_FASTCALLCC_TOK; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 46:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 238 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TY(Type::VoidTy, VOID); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 47:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 239 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2007-01-12 02:21:29 +08:00
|
|
|
{ RET_TY(Type::Int1Ty, BOOL); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 48:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 240 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
|
|
|
{ RET_TY(Type::FloatTy, FLOAT); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 49:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 241 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
|
|
|
{ RET_TY(Type::DoubleTy,DOUBLE);}
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 50:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 242 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
|
|
|
{ RET_TY(Type::LabelTy, LABEL); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 51:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 243 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
|
|
|
{ return TYPE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case 52:
|
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 244 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
|
|
|
{ return OPAQUE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
2006-12-31 13:40:51 +08:00
|
|
|
case 53:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 245 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
|
|
|
{ uint64_t NumBits = atoull(yytext+1);
|
|
|
|
if (NumBits < IntegerType::MIN_INT_BITS ||
|
|
|
|
NumBits > IntegerType::MAX_INT_BITS)
|
|
|
|
GenerateError("Bitwidth for integer type out of range!");
|
|
|
|
const Type* Ty = IntegerType::get(NumBits);
|
|
|
|
RET_TY(Ty, INTTYPE);
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
2006-12-31 13:40:51 +08:00
|
|
|
case 54:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 253 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, Add, ADD); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 55:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 254 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, Sub, SUB); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 56:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 255 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, Mul, MUL); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 57:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 256 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, UDiv, UDIV); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 58:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 257 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, SDiv, SDIV); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 59:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 258 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, FDiv, FDIV); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 60:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 259 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, URem, UREM); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 61:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 260 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, SRem, SREM); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 62:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 261 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, FRem, FREM); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 63:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 262 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, And, AND); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 64:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 263 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, Or , OR ); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 65:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 264 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(BinaryOpVal, Xor, XOR); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 66:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 265 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, ICmp, ICMP); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 67:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 266 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, FCmp, FCMP); }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 68:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 267 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return EQ; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 69:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 268 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return NE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 70:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 269 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return SLT; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 71:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 270 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return SGT; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 72:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 271 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return SLE; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 73:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 272 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return SGE; }
|
2005-11-05 17:21:28 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 74:
|
2005-11-05 17:21:28 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 273 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return ULT; }
|
2005-11-12 08:11:49 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 75:
|
2005-11-12 08:11:49 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 274 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return UGT; }
|
2006-01-11 03:04:32 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 76:
|
2006-01-11 03:04:32 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 275 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return ULE; }
|
2006-01-18 04:06:25 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 77:
|
2006-01-18 04:06:25 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 276 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return UGE; }
|
2006-01-24 07:05:42 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 78:
|
2006-01-24 07:05:42 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 277 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return OEQ; }
|
2006-01-24 12:14:29 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 79:
|
2006-01-24 12:14:29 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 278 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return ONE; }
|
2006-01-26 06:27:16 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 80:
|
2006-01-26 06:27:16 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 279 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return OLT; }
|
2006-04-08 09:18:56 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 81:
|
2006-04-08 09:18:56 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 280 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return OGT; }
|
2006-05-20 05:28:53 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 82:
|
2006-05-20 05:28:53 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 281 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return OLE; }
|
2006-09-15 02:25:26 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 83:
|
2006-09-15 02:25:26 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 282 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return OGE; }
|
2006-09-15 02:25:26 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 84:
|
2006-09-15 02:25:26 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 283 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return ORD; }
|
2006-09-15 02:25:26 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 85:
|
2006-09-15 02:25:26 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 284 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return UNO; }
|
2006-09-18 04:25:45 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 86:
|
2006-09-18 04:25:45 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 285 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return UEQ; }
|
2006-09-18 04:25:45 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 87:
|
2006-09-18 04:25:45 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 286 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ return UNE; }
|
2006-11-03 04:25:50 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 88:
|
2006-11-03 04:25:50 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 288 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, PHI, PHI_TOK); }
|
2006-11-03 04:25:50 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 89:
|
2006-11-03 04:25:50 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 289 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, Call, CALL); }
|
2006-11-03 04:25:50 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 90:
|
2006-11-03 04:25:50 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 290 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, Trunc, TRUNC); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 91:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 291 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, ZExt, ZEXT); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 92:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 292 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, SExt, SEXT); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 93:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 293 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, FPTrunc, FPTRUNC); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 94:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 294 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, FPExt, FPEXT); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 95:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 295 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, UIToFP, UITOFP); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 96:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 296 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, SIToFP, SITOFP); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 97:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 297 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, FPToUI, FPTOUI); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 98:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 298 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, FPToSI, FPTOSI); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 99:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 299 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, IntToPtr, INTTOPTR); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 100:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 300 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, PtrToInt, PTRTOINT); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 101:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 301 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(CastOpVal, BitCast, BITCAST); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 102:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 302 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, Select, SELECT); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 103:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 303 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, Shl, SHL); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 104:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 304 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, LShr, LSHR); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 105:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 305 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, AShr, ASHR); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 106:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 306 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, VAArg , VAARG); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 107:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 307 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(TermOpVal, Ret, RET); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 108:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 308 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(TermOpVal, Br, BR); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 109:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 309 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(TermOpVal, Switch, SWITCH); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 110:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 310 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(TermOpVal, Invoke, INVOKE); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 111:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 311 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(TermOpVal, Unwind, UNWIND); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 112:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 312 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(TermOpVal, Unreachable, UNREACHABLE); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 113:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 314 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(MemOpVal, Malloc, MALLOC); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 114:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 315 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(MemOpVal, Alloca, ALLOCA); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 115:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 316 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(MemOpVal, Free, FREE); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 116:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 317 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(MemOpVal, Load, LOAD); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 117:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 318 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(MemOpVal, Store, STORE); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 118:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 319 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(MemOpVal, GetElementPtr, GETELEMENTPTR); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 119:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 321 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, ExtractElement, EXTRACTELEMENT); }
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 120:
|
2006-12-03 13:46:11 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 322 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, InsertElement, INSERTELEMENT); }
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 121:
|
2006-11-27 09:05:10 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 323 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-12-30 04:35:03 +08:00
|
|
|
{ RET_TOK(OtherOpVal, ShuffleVector, SHUFFLEVECTOR); }
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 122:
|
2006-12-30 04:35:03 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 326 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
UnEscapeLexed(yytext+1);
|
|
|
|
llvmAsmlval.StrVal = strdup(yytext+1); // Skip %
|
2005-08-28 02:50:39 +08:00
|
|
|
return VAR_ID;
|
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 123:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 331 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
yytext[strlen(yytext)-1] = 0; // nuke colon
|
|
|
|
UnEscapeLexed(yytext);
|
|
|
|
llvmAsmlval.StrVal = strdup(yytext);
|
2005-08-28 02:50:39 +08:00
|
|
|
return LABELSTR;
|
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 124:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 337 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
yytext[strlen(yytext)-2] = 0; // nuke colon, end quote
|
|
|
|
UnEscapeLexed(yytext+1);
|
|
|
|
llvmAsmlval.StrVal = strdup(yytext+1);
|
2005-08-28 02:50:39 +08:00
|
|
|
return LABELSTR;
|
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 125:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 344 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{ // Note that we cannot unescape a string constant here! The
|
|
|
|
// string constant might contain a \00 which would not be
|
|
|
|
// understood by the string stuff. It is valid to make a
|
|
|
|
// [sbyte] c"Hello World\00" constant, for example.
|
|
|
|
//
|
2006-10-18 10:21:48 +08:00
|
|
|
yytext[strlen(yytext)-1] = 0; // nuke end quote
|
|
|
|
llvmAsmlval.StrVal = strdup(yytext+1); // Nuke start quote
|
2005-08-28 02:50:39 +08:00
|
|
|
return STRINGCONSTANT;
|
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 126:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 355 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-10-18 10:21:48 +08:00
|
|
|
{ llvmAsmlval.UInt64Val = atoull(yytext); return EUINT64VAL; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 127:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 356 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
uint64_t Val = atoull(yytext+1);
|
2005-08-28 02:50:39 +08:00
|
|
|
// +1: we have bigger negative range
|
|
|
|
if (Val > (uint64_t)INT64_MAX+1)
|
2006-08-18 16:43:06 +08:00
|
|
|
GenerateError("Constant too large for signed 64 bits!");
|
2005-08-28 02:50:39 +08:00
|
|
|
llvmAsmlval.SInt64Val = -Val;
|
|
|
|
return ESINT64VAL;
|
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 128:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 364 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
llvmAsmlval.UInt64Val = HexIntToVal(yytext+3);
|
|
|
|
return yytext[0] == 's' ? ESINT64VAL : EUINT64VAL;
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 129:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 369 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
uint64_t Val = atoull(yytext+1);
|
2005-08-28 02:50:39 +08:00
|
|
|
if ((unsigned)Val != Val)
|
2006-08-18 16:43:06 +08:00
|
|
|
GenerateError("Invalid value number (too large)!");
|
2005-08-28 02:50:39 +08:00
|
|
|
llvmAsmlval.UIntVal = unsigned(Val);
|
|
|
|
return UINTVAL;
|
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 130:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 376 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
uint64_t Val = atoull(yytext+2);
|
2005-08-28 02:50:39 +08:00
|
|
|
// +1: we have bigger negative range
|
|
|
|
if (Val > (uint64_t)INT32_MAX+1)
|
2006-08-18 16:43:06 +08:00
|
|
|
GenerateError("Constant too large for signed 32 bits!");
|
2005-08-28 02:50:39 +08:00
|
|
|
llvmAsmlval.SIntVal = (int)-Val;
|
|
|
|
return SINTVAL;
|
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 131:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 385 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-10-18 10:21:48 +08:00
|
|
|
{ llvmAsmlval.FPVal = atof(yytext); return FPVAL; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 132:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 386 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-10-18 10:21:48 +08:00
|
|
|
{ llvmAsmlval.FPVal = HexToFP(yytext); return FPVAL; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
|
|
|
case YY_STATE_EOF(INITIAL):
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 388 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
/* Make sure to free the internal buffers for flex when we are
|
|
|
|
* done reading our input!
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_delete_buffer(YY_CURRENT_BUFFER);
|
2005-08-28 02:50:39 +08:00
|
|
|
return EOF;
|
|
|
|
}
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 133:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 396 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
{ /* Ignore whitespace */ }
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 134:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 397 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-10-18 10:21:48 +08:00
|
|
|
{ return yytext[0]; }
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
case 135:
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RULE_SETUP
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 399 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_FATAL_ERROR( "flex scanner jammed" );
|
|
|
|
YY_BREAK
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 2010 "Lexer.cpp"
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
case YY_END_OF_BUFFER:
|
|
|
|
{
|
|
|
|
/* Amount of text matched not including the EOB char. */
|
2006-10-18 10:21:48 +08:00
|
|
|
int yy_amount_of_matched_text = (int) (yy_cp - yytext_ptr) - 1;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* Undo the effects of YY_DO_BEFORE_ACTION. */
|
2006-10-18 10:21:48 +08:00
|
|
|
*yy_cp = yy_hold_char;
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_RESTORE_YY_MORE_OFFSET
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_current_buffer->yy_buffer_status == YY_BUFFER_NEW )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
/* We're scanning a new file or input source. It's
|
|
|
|
* possible that this happened because the user
|
2006-10-18 10:21:48 +08:00
|
|
|
* just pointed yyin at a new source and called
|
|
|
|
* yylex(). If so, then we have to assure
|
|
|
|
* consistency between yy_current_buffer and our
|
2005-08-28 02:50:39 +08:00
|
|
|
* globals. Here is the right place to do so, because
|
|
|
|
* this is the first action (other than possibly a
|
|
|
|
* back-up) that will match for the new input source.
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_n_chars = yy_current_buffer->yy_n_chars;
|
|
|
|
yy_current_buffer->yy_input_file = yyin;
|
|
|
|
yy_current_buffer->yy_buffer_status = YY_BUFFER_NORMAL;
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Note that here we test for yy_c_buf_p "<=" to the position
|
|
|
|
* of the first EOB in the buffer, since yy_c_buf_p will
|
|
|
|
* already have been incremented past the NUL character
|
|
|
|
* (since all states make transitions on EOB to the
|
|
|
|
* end-of-buffer state). Contrast this with the test
|
|
|
|
* in input().
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_c_buf_p <= &yy_current_buffer->yy_ch_buf[yy_n_chars] )
|
2005-08-28 02:50:39 +08:00
|
|
|
{ /* This was really a NUL. */
|
|
|
|
yy_state_type yy_next_state;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_c_buf_p = yytext_ptr + yy_amount_of_matched_text;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_state = yy_get_previous_state();
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* Okay, we're now positioned to make the NUL
|
|
|
|
* transition. We couldn't have
|
|
|
|
* yy_get_previous_state() go ahead and do it
|
|
|
|
* for us because it doesn't know how to deal
|
|
|
|
* with the possibility of jamming (and we don't
|
|
|
|
* want to build jamming into it because then it
|
|
|
|
* will run more slowly).
|
|
|
|
*/
|
|
|
|
|
|
|
|
yy_next_state = yy_try_NUL_trans( yy_current_state );
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_bp = yytext_ptr + YY_MORE_ADJ;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
if ( yy_next_state )
|
|
|
|
{
|
|
|
|
/* Consume the NUL. */
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_cp = ++yy_c_buf_p;
|
2005-08-28 02:50:39 +08:00
|
|
|
yy_current_state = yy_next_state;
|
|
|
|
goto yy_match;
|
|
|
|
}
|
|
|
|
|
|
|
|
else
|
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_cp = yy_c_buf_p;
|
2005-08-28 02:50:39 +08:00
|
|
|
goto yy_find_action;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
else switch ( yy_get_next_buffer() )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
case EOB_ACT_END_OF_FILE:
|
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_did_buffer_switch_on_eof = 0;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yywrap() )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
/* Note: because we've taken care in
|
|
|
|
* yy_get_next_buffer() to have set up
|
2006-10-18 10:21:48 +08:00
|
|
|
* yytext, we can now set up
|
2005-08-28 02:50:39 +08:00
|
|
|
* yy_c_buf_p so that if some total
|
|
|
|
* hoser (like flex itself) wants to
|
|
|
|
* call the scanner after we return the
|
|
|
|
* YY_NULL, it'll still work - another
|
|
|
|
* YY_NULL will get returned.
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_c_buf_p = yytext_ptr + YY_MORE_ADJ;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
yy_act = YY_STATE_EOF(YY_START);
|
|
|
|
goto do_action;
|
|
|
|
}
|
|
|
|
|
|
|
|
else
|
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_did_buffer_switch_on_eof )
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_NEW_FILE;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case EOB_ACT_CONTINUE_SCAN:
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_c_buf_p =
|
|
|
|
yytext_ptr + yy_amount_of_matched_text;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_state = yy_get_previous_state();
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_cp = yy_c_buf_p;
|
|
|
|
yy_bp = yytext_ptr + YY_MORE_ADJ;
|
2005-08-28 02:50:39 +08:00
|
|
|
goto yy_match;
|
|
|
|
|
|
|
|
case EOB_ACT_LAST_MATCH:
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_c_buf_p =
|
|
|
|
&yy_current_buffer->yy_ch_buf[yy_n_chars];
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_state = yy_get_previous_state();
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_cp = yy_c_buf_p;
|
|
|
|
yy_bp = yytext_ptr + YY_MORE_ADJ;
|
2005-08-28 02:50:39 +08:00
|
|
|
goto yy_find_action;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
default:
|
|
|
|
YY_FATAL_ERROR(
|
|
|
|
"fatal flex scanner internal error--no action found" );
|
|
|
|
} /* end of action switch */
|
|
|
|
} /* end of scanning one token */
|
2006-10-18 10:21:48 +08:00
|
|
|
} /* end of yylex */
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* yy_get_next_buffer - try to read in a new buffer
|
|
|
|
*
|
|
|
|
* Returns a code representing an action:
|
|
|
|
* EOB_ACT_LAST_MATCH -
|
|
|
|
* EOB_ACT_CONTINUE_SCAN - continue scanning from current position
|
|
|
|
* EOB_ACT_END_OF_FILE - end of file
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
static int yy_get_next_buffer()
|
|
|
|
{
|
|
|
|
register char *dest = yy_current_buffer->yy_ch_buf;
|
|
|
|
register char *source = yytext_ptr;
|
2005-08-28 02:50:39 +08:00
|
|
|
register int number_to_move, i;
|
|
|
|
int ret_val;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_c_buf_p > &yy_current_buffer->yy_ch_buf[yy_n_chars + 1] )
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_FATAL_ERROR(
|
|
|
|
"fatal flex scanner internal error--end of buffer missed" );
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_current_buffer->yy_fill_buffer == 0 )
|
2005-08-28 02:50:39 +08:00
|
|
|
{ /* Don't try to fill the buffer, so this is an EOF. */
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_c_buf_p - yytext_ptr - YY_MORE_ADJ == 1 )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
/* We matched a single character, the EOB, so
|
|
|
|
* treat this as a final EOF.
|
|
|
|
*/
|
|
|
|
return EOB_ACT_END_OF_FILE;
|
|
|
|
}
|
|
|
|
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* We matched some text prior to the EOB, first
|
|
|
|
* process it.
|
|
|
|
*/
|
|
|
|
return EOB_ACT_LAST_MATCH;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Try to read more data. */
|
|
|
|
|
|
|
|
/* First move last chars to start of buffer. */
|
2006-10-18 10:21:48 +08:00
|
|
|
number_to_move = (int) (yy_c_buf_p - yytext_ptr) - 1;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
for ( i = 0; i < number_to_move; ++i )
|
|
|
|
*(dest++) = *(source++);
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_current_buffer->yy_buffer_status == YY_BUFFER_EOF_PENDING )
|
2005-08-28 02:50:39 +08:00
|
|
|
/* don't do the read, it's not guaranteed to return an EOF,
|
|
|
|
* just force an EOF
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_buffer->yy_n_chars = yy_n_chars = 0;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
else
|
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
int num_to_read =
|
|
|
|
yy_current_buffer->yy_buf_size - number_to_move - 1;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
while ( num_to_read <= 0 )
|
|
|
|
{ /* Not enough room in the buffer - grow it. */
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USES_REJECT
|
|
|
|
YY_FATAL_ERROR(
|
|
|
|
"input buffer overflow, can't enlarge buffer because scanner uses REJECT" );
|
|
|
|
#else
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* just a shorter name for the current buffer */
|
2006-10-18 10:21:48 +08:00
|
|
|
YY_BUFFER_STATE b = yy_current_buffer;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
int yy_c_buf_p_offset =
|
2006-10-18 10:21:48 +08:00
|
|
|
(int) (yy_c_buf_p - b->yy_ch_buf);
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
if ( b->yy_is_our_buffer )
|
|
|
|
{
|
|
|
|
int new_size = b->yy_buf_size * 2;
|
|
|
|
|
|
|
|
if ( new_size <= 0 )
|
|
|
|
b->yy_buf_size += b->yy_buf_size / 8;
|
|
|
|
else
|
|
|
|
b->yy_buf_size *= 2;
|
|
|
|
|
|
|
|
b->yy_ch_buf = (char *)
|
|
|
|
/* Include room in for 2 EOB chars. */
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_flex_realloc( (void *) b->yy_ch_buf,
|
|
|
|
b->yy_buf_size + 2 );
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
/* Can't grow it, we don't own it. */
|
|
|
|
b->yy_ch_buf = 0;
|
|
|
|
|
|
|
|
if ( ! b->yy_ch_buf )
|
|
|
|
YY_FATAL_ERROR(
|
|
|
|
"fatal error - scanner input buffer overflow" );
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_c_buf_p = &b->yy_ch_buf[yy_c_buf_p_offset];
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
num_to_read = yy_current_buffer->yy_buf_size -
|
2005-08-28 02:50:39 +08:00
|
|
|
number_to_move - 1;
|
2006-10-18 10:21:48 +08:00
|
|
|
#endif
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if ( num_to_read > YY_READ_BUF_SIZE )
|
|
|
|
num_to_read = YY_READ_BUF_SIZE;
|
|
|
|
|
|
|
|
/* Read in more data. */
|
2006-10-18 10:21:48 +08:00
|
|
|
YY_INPUT( (&yy_current_buffer->yy_ch_buf[number_to_move]),
|
|
|
|
yy_n_chars, num_to_read );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_buffer->yy_n_chars = yy_n_chars;
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_n_chars == 0 )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
if ( number_to_move == YY_MORE_ADJ )
|
|
|
|
{
|
|
|
|
ret_val = EOB_ACT_END_OF_FILE;
|
2006-10-18 10:21:48 +08:00
|
|
|
yyrestart( yyin );
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ret_val = EOB_ACT_LAST_MATCH;
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_buffer->yy_buffer_status =
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BUFFER_EOF_PENDING;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
else
|
|
|
|
ret_val = EOB_ACT_CONTINUE_SCAN;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_n_chars += number_to_move;
|
|
|
|
yy_current_buffer->yy_ch_buf[yy_n_chars] = YY_END_OF_BUFFER_CHAR;
|
|
|
|
yy_current_buffer->yy_ch_buf[yy_n_chars + 1] = YY_END_OF_BUFFER_CHAR;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yytext_ptr = &yy_current_buffer->yy_ch_buf[0];
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
return ret_val;
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* yy_get_previous_state - get the state just before the EOB char was reached */
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
static yy_state_type yy_get_previous_state()
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
register yy_state_type yy_current_state;
|
|
|
|
register char *yy_cp;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_state = yy_start;
|
|
|
|
yy_state_ptr = yy_state_buf;
|
|
|
|
*yy_state_ptr++ = yy_current_state;
|
|
|
|
|
|
|
|
for ( yy_cp = yytext_ptr + YY_MORE_ADJ; yy_cp < yy_c_buf_p; ++yy_cp )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
register YY_CHAR yy_c = (*yy_cp ? yy_ec[YY_SC_TO_UI(*yy_cp)] : 1);
|
|
|
|
while ( yy_chk[yy_base[yy_current_state] + yy_c] != yy_current_state )
|
|
|
|
{
|
|
|
|
yy_current_state = (int) yy_def[yy_current_state];
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
if ( yy_current_state >= 551 )
|
2005-08-28 02:50:39 +08:00
|
|
|
yy_c = yy_meta[(unsigned int) yy_c];
|
|
|
|
}
|
|
|
|
yy_current_state = yy_nxt[yy_base[yy_current_state] + (unsigned int) yy_c];
|
2006-10-18 10:21:48 +08:00
|
|
|
*yy_state_ptr++ = yy_current_state;
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return yy_current_state;
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* yy_try_NUL_trans - try to make a transition on the NUL character
|
|
|
|
*
|
|
|
|
* synopsis
|
|
|
|
* next_state = yy_try_NUL_trans( current_state );
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static yy_state_type yy_try_NUL_trans( yy_state_type yy_current_state )
|
|
|
|
#else
|
|
|
|
static yy_state_type yy_try_NUL_trans( yy_current_state )
|
|
|
|
yy_state_type yy_current_state;
|
|
|
|
#endif
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
register int yy_is_jam;
|
|
|
|
|
|
|
|
register YY_CHAR yy_c = 1;
|
|
|
|
while ( yy_chk[yy_base[yy_current_state] + yy_c] != yy_current_state )
|
|
|
|
{
|
|
|
|
yy_current_state = (int) yy_def[yy_current_state];
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
if ( yy_current_state >= 551 )
|
2005-08-28 02:50:39 +08:00
|
|
|
yy_c = yy_meta[(unsigned int) yy_c];
|
|
|
|
}
|
|
|
|
yy_current_state = yy_nxt[yy_base[yy_current_state] + (unsigned int) yy_c];
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
yy_is_jam = (yy_current_state == 550);
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_is_jam )
|
|
|
|
*yy_state_ptr++ = yy_current_state;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
return yy_is_jam ? 0 : yy_current_state;
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifndef YY_NO_UNPUT
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static inline void yyunput( int c, register char *yy_bp )
|
|
|
|
#else
|
|
|
|
static inline void yyunput( c, yy_bp )
|
|
|
|
int c;
|
|
|
|
register char *yy_bp;
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
register char *yy_cp = yy_c_buf_p;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* undo effects of setting up yytext */
|
|
|
|
*yy_cp = yy_hold_char;
|
|
|
|
|
|
|
|
if ( yy_cp < yy_current_buffer->yy_ch_buf + 2 )
|
2005-08-28 02:50:39 +08:00
|
|
|
{ /* need to shift things up to make room */
|
|
|
|
/* +2 for EOB chars. */
|
2006-10-18 10:21:48 +08:00
|
|
|
register int number_to_move = yy_n_chars + 2;
|
|
|
|
register char *dest = &yy_current_buffer->yy_ch_buf[
|
|
|
|
yy_current_buffer->yy_buf_size + 2];
|
2005-08-28 02:50:39 +08:00
|
|
|
register char *source =
|
2006-10-18 10:21:48 +08:00
|
|
|
&yy_current_buffer->yy_ch_buf[number_to_move];
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
while ( source > yy_current_buffer->yy_ch_buf )
|
2005-08-28 02:50:39 +08:00
|
|
|
*--dest = *--source;
|
|
|
|
|
|
|
|
yy_cp += (int) (dest - source);
|
|
|
|
yy_bp += (int) (dest - source);
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_buffer->yy_n_chars =
|
|
|
|
yy_n_chars = yy_current_buffer->yy_buf_size;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_cp < yy_current_buffer->yy_ch_buf + 2 )
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_FATAL_ERROR( "flex scanner push-back overflow" );
|
|
|
|
}
|
|
|
|
|
|
|
|
*--yy_cp = (char) c;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( c == '\n' )
|
|
|
|
--yylineno;
|
|
|
|
|
|
|
|
yytext_ptr = yy_bp;
|
|
|
|
yy_hold_char = *yy_cp;
|
|
|
|
yy_c_buf_p = yy_cp;
|
|
|
|
}
|
|
|
|
#endif /* ifndef YY_NO_UNPUT */
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-11-27 09:05:10 +08:00
|
|
|
#ifndef YY_NO_INPUT
|
2005-08-28 02:50:39 +08:00
|
|
|
#ifdef __cplusplus
|
2006-10-18 10:21:48 +08:00
|
|
|
static int yyinput()
|
2005-08-28 02:50:39 +08:00
|
|
|
#else
|
2006-10-18 10:21:48 +08:00
|
|
|
static int input()
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
2006-10-18 10:21:48 +08:00
|
|
|
{
|
2006-09-15 02:25:26 +08:00
|
|
|
int c;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
*yy_c_buf_p = yy_hold_char;
|
|
|
|
|
|
|
|
if ( *yy_c_buf_p == YY_END_OF_BUFFER_CHAR )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
/* yy_c_buf_p now points to the character we want to return.
|
|
|
|
* If this occurs *before* the EOB characters, then it's a
|
|
|
|
* valid NUL; if not, then we've hit the end of the buffer.
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_c_buf_p < &yy_current_buffer->yy_ch_buf[yy_n_chars] )
|
2005-08-28 02:50:39 +08:00
|
|
|
/* This was really a NUL. */
|
2006-10-18 10:21:48 +08:00
|
|
|
*yy_c_buf_p = '\0';
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
else
|
|
|
|
{ /* need more input */
|
2006-10-18 10:21:48 +08:00
|
|
|
int offset = yy_c_buf_p - yytext_ptr;
|
|
|
|
++yy_c_buf_p;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
switch ( yy_get_next_buffer() )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
case EOB_ACT_LAST_MATCH:
|
|
|
|
/* This happens because yy_g_n_b()
|
|
|
|
* sees that we've accumulated a
|
|
|
|
* token and flags that we need to
|
|
|
|
* try matching the token before
|
|
|
|
* proceeding. But for input(),
|
|
|
|
* there's no matching to consider.
|
|
|
|
* So convert the EOB_ACT_LAST_MATCH
|
|
|
|
* to EOB_ACT_END_OF_FILE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Reset buffer status. */
|
2006-10-18 10:21:48 +08:00
|
|
|
yyrestart( yyin );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* fall through */
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
case EOB_ACT_END_OF_FILE:
|
|
|
|
{
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yywrap() )
|
2006-08-18 16:43:06 +08:00
|
|
|
return EOF;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_did_buffer_switch_on_eof )
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_NEW_FILE;
|
|
|
|
#ifdef __cplusplus
|
|
|
|
return yyinput();
|
|
|
|
#else
|
|
|
|
return input();
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
case EOB_ACT_CONTINUE_SCAN:
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_c_buf_p = yytext_ptr + offset;
|
2005-08-28 02:50:39 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
c = *(unsigned char *) yy_c_buf_p; /* cast for 8-bit char's */
|
|
|
|
*yy_c_buf_p = '\0'; /* preserve yytext */
|
|
|
|
yy_hold_char = *++yy_c_buf_p;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
if ( c == '\n' )
|
2006-10-18 10:21:48 +08:00
|
|
|
++yylineno;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
return c;
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
2006-11-27 09:05:10 +08:00
|
|
|
#endif /* YY_NO_INPUT */
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
void yyrestart( FILE *input_file )
|
|
|
|
#else
|
|
|
|
void yyrestart( input_file )
|
|
|
|
FILE *input_file;
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
if ( ! yy_current_buffer )
|
|
|
|
yy_current_buffer = yy_create_buffer( yyin, YY_BUF_SIZE );
|
|
|
|
|
|
|
|
yy_init_buffer( yy_current_buffer, input_file );
|
|
|
|
yy_load_buffer_state();
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
void yy_switch_to_buffer( YY_BUFFER_STATE new_buffer )
|
|
|
|
#else
|
|
|
|
void yy_switch_to_buffer( new_buffer )
|
|
|
|
YY_BUFFER_STATE new_buffer;
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
if ( yy_current_buffer == new_buffer )
|
2005-08-28 02:50:39 +08:00
|
|
|
return;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( yy_current_buffer )
|
2005-08-28 02:50:39 +08:00
|
|
|
{
|
|
|
|
/* Flush out information for old buffer. */
|
2006-10-18 10:21:48 +08:00
|
|
|
*yy_c_buf_p = yy_hold_char;
|
|
|
|
yy_current_buffer->yy_buf_pos = yy_c_buf_p;
|
|
|
|
yy_current_buffer->yy_n_chars = yy_n_chars;
|
2005-08-28 02:50:39 +08:00
|
|
|
}
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_current_buffer = new_buffer;
|
|
|
|
yy_load_buffer_state();
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* We don't actually know whether we did this switch during
|
2006-10-18 10:21:48 +08:00
|
|
|
* EOF (yywrap()) processing, but the only time this flag
|
|
|
|
* is looked at is after yywrap() is called, so it's safe
|
2005-08-28 02:50:39 +08:00
|
|
|
* to go ahead and always set it.
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_did_buffer_switch_on_eof = 1;
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
void yy_load_buffer_state( void )
|
|
|
|
#else
|
|
|
|
void yy_load_buffer_state()
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
yy_n_chars = yy_current_buffer->yy_n_chars;
|
|
|
|
yytext_ptr = yy_c_buf_p = yy_current_buffer->yy_buf_pos;
|
|
|
|
yyin = yy_current_buffer->yy_input_file;
|
|
|
|
yy_hold_char = *yy_c_buf_p;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
YY_BUFFER_STATE yy_create_buffer( FILE *file, int size )
|
|
|
|
#else
|
|
|
|
YY_BUFFER_STATE yy_create_buffer( file, size )
|
|
|
|
FILE *file;
|
|
|
|
int size;
|
|
|
|
#endif
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BUFFER_STATE b;
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
b = (YY_BUFFER_STATE) yy_flex_alloc( sizeof( struct yy_buffer_state ) );
|
2005-08-28 02:50:39 +08:00
|
|
|
if ( ! b )
|
2006-10-18 10:21:48 +08:00
|
|
|
YY_FATAL_ERROR( "out of dynamic memory in yy_create_buffer()" );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
b->yy_buf_size = size;
|
|
|
|
|
|
|
|
/* yy_ch_buf has to be 2 characters longer than the size given because
|
|
|
|
* we need to put in 2 end-of-buffer characters.
|
|
|
|
*/
|
2006-10-18 10:21:48 +08:00
|
|
|
b->yy_ch_buf = (char *) yy_flex_alloc( b->yy_buf_size + 2 );
|
2005-08-28 02:50:39 +08:00
|
|
|
if ( ! b->yy_ch_buf )
|
2006-10-18 10:21:48 +08:00
|
|
|
YY_FATAL_ERROR( "out of dynamic memory in yy_create_buffer()" );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
b->yy_is_our_buffer = 1;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_init_buffer( b, file );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
return b;
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
void yy_delete_buffer( YY_BUFFER_STATE b )
|
|
|
|
#else
|
|
|
|
void yy_delete_buffer( b )
|
|
|
|
YY_BUFFER_STATE b;
|
|
|
|
#endif
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
if ( ! b )
|
|
|
|
return;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( b == yy_current_buffer )
|
|
|
|
yy_current_buffer = (YY_BUFFER_STATE) 0;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
if ( b->yy_is_our_buffer )
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_flex_free( (void *) b->yy_ch_buf );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_flex_free( (void *) b );
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
void yy_init_buffer( YY_BUFFER_STATE b, FILE *file )
|
|
|
|
#else
|
|
|
|
void yy_init_buffer( b, file )
|
|
|
|
YY_BUFFER_STATE b;
|
|
|
|
FILE *file;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
yy_flush_buffer( b );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
b->yy_input_file = file;
|
|
|
|
b->yy_fill_buffer = 1;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#if YY_ALWAYS_INTERACTIVE
|
|
|
|
b->yy_is_interactive = 1;
|
|
|
|
#else
|
|
|
|
#if YY_NEVER_INTERACTIVE
|
|
|
|
b->yy_is_interactive = 0;
|
|
|
|
#else
|
|
|
|
b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
void yy_flush_buffer( YY_BUFFER_STATE b )
|
|
|
|
#else
|
|
|
|
void yy_flush_buffer( b )
|
|
|
|
YY_BUFFER_STATE b;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
{
|
|
|
|
if ( ! b )
|
2005-08-28 02:50:39 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
b->yy_n_chars = 0;
|
|
|
|
|
|
|
|
/* We always need two end-of-buffer characters. The first causes
|
|
|
|
* a transition to the end-of-buffer state. The second causes
|
|
|
|
* a jam in that state.
|
|
|
|
*/
|
|
|
|
b->yy_ch_buf[0] = YY_END_OF_BUFFER_CHAR;
|
|
|
|
b->yy_ch_buf[1] = YY_END_OF_BUFFER_CHAR;
|
|
|
|
|
|
|
|
b->yy_buf_pos = &b->yy_ch_buf[0];
|
|
|
|
|
|
|
|
b->yy_at_bol = 1;
|
|
|
|
b->yy_buffer_status = YY_BUFFER_NEW;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( b == yy_current_buffer )
|
|
|
|
yy_load_buffer_state();
|
2006-09-15 02:25:26 +08:00
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-09-15 02:25:26 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifndef YY_NO_SCAN_BUFFER
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
YY_BUFFER_STATE yy_scan_buffer( char *base, yy_size_t size )
|
|
|
|
#else
|
|
|
|
YY_BUFFER_STATE yy_scan_buffer( base, size )
|
|
|
|
char *base;
|
|
|
|
yy_size_t size;
|
|
|
|
#endif
|
|
|
|
{
|
2006-09-15 02:25:26 +08:00
|
|
|
YY_BUFFER_STATE b;
|
2006-10-18 10:21:48 +08:00
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
if ( size < 2 ||
|
|
|
|
base[size-2] != YY_END_OF_BUFFER_CHAR ||
|
|
|
|
base[size-1] != YY_END_OF_BUFFER_CHAR )
|
|
|
|
/* They forgot to leave room for the EOB's. */
|
|
|
|
return 0;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
b = (YY_BUFFER_STATE) yy_flex_alloc( sizeof( struct yy_buffer_state ) );
|
2005-08-28 02:50:39 +08:00
|
|
|
if ( ! b )
|
2006-10-18 10:21:48 +08:00
|
|
|
YY_FATAL_ERROR( "out of dynamic memory in yy_scan_buffer()" );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
b->yy_buf_size = size - 2; /* "- 2" to take care of EOB's */
|
|
|
|
b->yy_buf_pos = b->yy_ch_buf = base;
|
|
|
|
b->yy_is_our_buffer = 0;
|
|
|
|
b->yy_input_file = 0;
|
|
|
|
b->yy_n_chars = b->yy_buf_size;
|
|
|
|
b->yy_is_interactive = 0;
|
|
|
|
b->yy_at_bol = 1;
|
|
|
|
b->yy_fill_buffer = 0;
|
|
|
|
b->yy_buffer_status = YY_BUFFER_NEW;
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_switch_to_buffer( b );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
return b;
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
|
|
|
#endif
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifndef YY_NO_SCAN_STRING
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
YY_BUFFER_STATE yy_scan_string( yyconst char *yy_str )
|
|
|
|
#else
|
|
|
|
YY_BUFFER_STATE yy_scan_string( yy_str )
|
|
|
|
yyconst char *yy_str;
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
int len;
|
|
|
|
for ( len = 0; yy_str[len]; ++len )
|
|
|
|
;
|
|
|
|
|
|
|
|
return yy_scan_bytes( yy_str, len );
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
#ifndef YY_NO_SCAN_BYTES
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
YY_BUFFER_STATE yy_scan_bytes( yyconst char *bytes, int len )
|
|
|
|
#else
|
|
|
|
YY_BUFFER_STATE yy_scan_bytes( bytes, len )
|
|
|
|
yyconst char *bytes;
|
|
|
|
int len;
|
|
|
|
#endif
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
YY_BUFFER_STATE b;
|
|
|
|
char *buf;
|
|
|
|
yy_size_t n;
|
|
|
|
int i;
|
2006-10-18 10:21:48 +08:00
|
|
|
|
2005-08-28 02:50:39 +08:00
|
|
|
/* Get memory for full buffer, including space for trailing EOB's. */
|
2006-10-18 10:21:48 +08:00
|
|
|
n = len + 2;
|
|
|
|
buf = (char *) yy_flex_alloc( n );
|
2005-08-28 02:50:39 +08:00
|
|
|
if ( ! buf )
|
2006-10-18 10:21:48 +08:00
|
|
|
YY_FATAL_ERROR( "out of dynamic memory in yy_scan_bytes()" );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
for ( i = 0; i < len; ++i )
|
|
|
|
buf[i] = bytes[i];
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
buf[len] = buf[len+1] = YY_END_OF_BUFFER_CHAR;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
b = yy_scan_buffer( buf, n );
|
2005-08-28 02:50:39 +08:00
|
|
|
if ( ! b )
|
2006-10-18 10:21:48 +08:00
|
|
|
YY_FATAL_ERROR( "bad buffer in yy_scan_bytes()" );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
/* It's okay to grow etc. this buffer, and we should throw it
|
|
|
|
* away when we're done.
|
|
|
|
*/
|
|
|
|
b->yy_is_our_buffer = 1;
|
|
|
|
|
|
|
|
return b;
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifndef YY_NO_PUSH_STATE
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static void yy_push_state( int new_state )
|
|
|
|
#else
|
|
|
|
static void yy_push_state( new_state )
|
|
|
|
int new_state;
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
if ( yy_start_stack_ptr >= yy_start_stack_depth )
|
|
|
|
{
|
|
|
|
yy_size_t new_size;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_start_stack_depth += YY_START_STACK_INCR;
|
|
|
|
new_size = yy_start_stack_depth * sizeof( int );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_start_stack )
|
|
|
|
yy_start_stack = (int *) yy_flex_alloc( new_size );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
else
|
|
|
|
yy_start_stack = (int *) yy_flex_realloc(
|
|
|
|
(void *) yy_start_stack, new_size );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
if ( ! yy_start_stack )
|
|
|
|
YY_FATAL_ERROR(
|
|
|
|
"out of memory expanding start-condition stack" );
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
yy_start_stack[yy_start_stack_ptr++] = YY_START;
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
BEGIN(new_state);
|
|
|
|
}
|
|
|
|
#endif
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifndef YY_NO_POP_STATE
|
|
|
|
static void yy_pop_state()
|
|
|
|
{
|
|
|
|
if ( --yy_start_stack_ptr < 0 )
|
|
|
|
YY_FATAL_ERROR( "start-condition stack underflow" );
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
BEGIN(yy_start_stack[yy_start_stack_ptr]);
|
|
|
|
}
|
|
|
|
#endif
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifndef YY_NO_TOP_STATE
|
|
|
|
static int yy_top_state()
|
|
|
|
{
|
|
|
|
return yy_start_stack[yy_start_stack_ptr - 1];
|
|
|
|
}
|
|
|
|
#endif
|
2006-09-15 02:25:26 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifndef YY_EXIT_FAILURE
|
|
|
|
#define YY_EXIT_FAILURE 2
|
|
|
|
#endif
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static void yy_fatal_error( yyconst char msg[] )
|
2005-08-28 02:50:39 +08:00
|
|
|
#else
|
2006-10-18 10:21:48 +08:00
|
|
|
static void yy_fatal_error( msg )
|
|
|
|
char msg[];
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
2006-10-18 10:21:48 +08:00
|
|
|
{
|
|
|
|
(void) fprintf( stderr, "%s\n", msg );
|
|
|
|
exit( YY_EXIT_FAILURE );
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* Redefine yyless() so it works in section 3 code. */
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#undef yyless
|
|
|
|
#define yyless(n) \
|
|
|
|
do \
|
|
|
|
{ \
|
|
|
|
/* Undo effects of setting up yytext. */ \
|
|
|
|
yytext[yyleng] = yy_hold_char; \
|
|
|
|
yy_c_buf_p = yytext + n; \
|
|
|
|
yy_hold_char = *yy_c_buf_p; \
|
|
|
|
*yy_c_buf_p = '\0'; \
|
|
|
|
yyleng = n; \
|
|
|
|
} \
|
|
|
|
while ( 0 )
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
/* Internal utility routines. */
|
2005-08-28 02:50:39 +08:00
|
|
|
|
|
|
|
#ifndef yytext_ptr
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static void yy_flex_strncpy( char *s1, yyconst char *s2, int n )
|
|
|
|
#else
|
|
|
|
static void yy_flex_strncpy( s1, s2, n )
|
|
|
|
char *s1;
|
|
|
|
yyconst char *s2;
|
|
|
|
int n;
|
|
|
|
#endif
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
register int i;
|
|
|
|
for ( i = 0; i < n; ++i )
|
|
|
|
s1[i] = s2[i];
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef YY_NEED_STRLEN
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static int yy_flex_strlen( yyconst char *s )
|
|
|
|
#else
|
|
|
|
static int yy_flex_strlen( s )
|
|
|
|
yyconst char *s;
|
|
|
|
#endif
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
register int n;
|
|
|
|
for ( n = 0; s[n]; ++n )
|
|
|
|
;
|
|
|
|
|
|
|
|
return n;
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
#endif
|
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
|
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static void *yy_flex_alloc( yy_size_t size )
|
|
|
|
#else
|
|
|
|
static void *yy_flex_alloc( size )
|
|
|
|
yy_size_t size;
|
|
|
|
#endif
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
return (void *) malloc( size );
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static inline void *yy_flex_realloc( void *ptr, yy_size_t size )
|
|
|
|
#else
|
|
|
|
static inline void *yy_flex_realloc( ptr, size )
|
|
|
|
void *ptr;
|
|
|
|
yy_size_t size;
|
|
|
|
#endif
|
|
|
|
{
|
2005-08-28 02:50:39 +08:00
|
|
|
/* The cast to (char *) in the following accommodates both
|
|
|
|
* implementations that use char* generic pointers, and those
|
|
|
|
* that use void* generic pointers. It works with the latter
|
|
|
|
* because both ANSI C and C++ allow castless assignment from
|
|
|
|
* any pointer type to void*, and deal with argument conversions
|
|
|
|
* as though doing an assignment.
|
|
|
|
*/
|
|
|
|
return (void *) realloc( (char *) ptr, size );
|
2006-10-18 10:21:48 +08:00
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#ifdef YY_USE_PROTOS
|
|
|
|
static void yy_flex_free( void *ptr )
|
|
|
|
#else
|
|
|
|
static void yy_flex_free( ptr )
|
|
|
|
void *ptr;
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
free( ptr );
|
|
|
|
}
|
2005-08-28 02:50:39 +08:00
|
|
|
|
2006-10-18 10:21:48 +08:00
|
|
|
#if YY_MAIN
|
|
|
|
int main()
|
|
|
|
{
|
|
|
|
yylex();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.
This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.
Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.
llvm-svn: 33113
2007-01-12 15:05:14 +08:00
|
|
|
#line 399 "/proj/llvm/llvm-1/lib/AsmParser/Lexer.l"
|
2006-02-15 15:02:59 +08:00
|
|
|
|