2009-01-02 15:01:27 +08:00
|
|
|
//===- LLToken.h - Token Codes for LLVM Assembly Files ----------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines the enums for the .ll lexer.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:26:38 +08:00
|
|
|
#ifndef LLVM_LIB_ASMPARSER_LLTOKEN_H
|
|
|
|
#define LLVM_LIB_ASMPARSER_LLTOKEN_H
|
2009-01-02 15:01:27 +08:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
namespace lltok {
|
|
|
|
enum Kind {
|
|
|
|
// Markers
|
|
|
|
Eof, Error,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// Tokens with no info.
|
|
|
|
dotdotdot, // ...
|
|
|
|
equal, comma, // = ,
|
|
|
|
star, // *
|
|
|
|
lsquare, rsquare, // [ ]
|
|
|
|
lbrace, rbrace, // { }
|
|
|
|
less, greater, // < >
|
|
|
|
lparen, rparen, // ( )
|
2009-12-30 12:56:59 +08:00
|
|
|
exclaim, // !
|
2015-02-21 09:02:18 +08:00
|
|
|
bar, // |
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_x,
|
|
|
|
kw_true, kw_false,
|
|
|
|
kw_declare, kw_define,
|
|
|
|
kw_global, kw_constant,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
llvm-svn: 203866
2014-03-14 07:18:37 +08:00
|
|
|
kw_private,
|
2012-08-18 02:33:14 +08:00
|
|
|
kw_internal,
|
2013-11-02 01:09:14 +08:00
|
|
|
kw_linkonce, kw_linkonce_odr,
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
kw_weak, // Used as a linkage, and a modifier for "cmpxchg".
|
|
|
|
kw_weak_odr, kw_appending,
|
2010-07-02 05:55:59 +08:00
|
|
|
kw_dllimport, kw_dllexport, kw_common, kw_available_externally,
|
Introduce new linkage types linkonce_odr, weak_odr, common_odr
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
llvm-svn: 66339
2009-03-07 23:45:40 +08:00
|
|
|
kw_default, kw_hidden, kw_protected,
|
2011-01-09 00:42:36 +08:00
|
|
|
kw_unnamed_addr,
|
2013-02-05 13:57:38 +08:00
|
|
|
kw_externally_initialized,
|
2009-03-11 16:08:06 +08:00
|
|
|
kw_extern_weak,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_external, kw_thread_local,
|
2012-06-23 19:37:03 +08:00
|
|
|
kw_localdynamic, kw_initialexec, kw_localexec,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_zeroinitializer,
|
2015-11-12 05:57:16 +08:00
|
|
|
kw_undef, kw_null, kw_none,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_to,
|
2015-08-01 01:58:14 +08:00
|
|
|
kw_caller,
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
kw_within,
|
|
|
|
kw_from,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_tail,
|
2014-04-25 04:14:34 +08:00
|
|
|
kw_musttail,
|
2015-11-07 07:55:38 +08:00
|
|
|
kw_notail,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_target,
|
|
|
|
kw_triple,
|
2012-06-23 19:37:03 +08:00
|
|
|
kw_unwind,
|
2012-11-28 16:41:48 +08:00
|
|
|
kw_deplibs, // FIXME: Remove in 4.0
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_datalayout,
|
|
|
|
kw_volatile,
|
2011-07-26 07:16:38 +08:00
|
|
|
kw_atomic,
|
|
|
|
kw_unordered, kw_monotonic, kw_acquire, kw_release, kw_acq_rel, kw_seq_cst,
|
|
|
|
kw_singlethread,
|
2012-11-27 08:42:44 +08:00
|
|
|
kw_nnan,
|
|
|
|
kw_ninf,
|
|
|
|
kw_nsz,
|
|
|
|
kw_arcp,
|
|
|
|
kw_fast,
|
2009-07-23 06:44:56 +08:00
|
|
|
kw_nuw,
|
|
|
|
kw_nsw,
|
2009-07-21 05:19:07 +08:00
|
|
|
kw_exact,
|
2009-07-28 05:53:46 +08:00
|
|
|
kw_inbounds,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_align,
|
|
|
|
kw_addrspace,
|
|
|
|
kw_section,
|
|
|
|
kw_alias,
|
|
|
|
kw_module,
|
|
|
|
kw_asm,
|
|
|
|
kw_sideeffect,
|
2009-10-22 07:28:00 +08:00
|
|
|
kw_alignstack,
|
2012-09-06 03:00:49 +08:00
|
|
|
kw_inteldialect,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_gc,
|
2013-09-16 09:08:15 +08:00
|
|
|
kw_prefix,
|
2014-12-03 10:08:38 +08:00
|
|
|
kw_prologue,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_c,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-06-17 02:50:49 +08:00
|
|
|
kw_cc, kw_ccc, kw_fastcc, kw_coldcc,
|
2013-07-12 14:02:35 +08:00
|
|
|
kw_intel_ocl_bicc,
|
2014-10-28 09:29:26 +08:00
|
|
|
kw_x86_stdcallcc, kw_x86_fastcallcc, kw_x86_thiscallcc, kw_x86_vectorcallcc,
|
2009-06-17 02:50:49 +08:00
|
|
|
kw_arm_apcscc, kw_arm_aapcscc, kw_arm_aapcs_vfpcc,
|
2009-12-07 10:27:35 +08:00
|
|
|
kw_msp430_intrcc,
|
2016-03-03 18:08:02 +08:00
|
|
|
kw_avr_intrcc, kw_avr_signalcc,
|
2010-09-25 15:46:17 +08:00
|
|
|
kw_ptx_kernel, kw_ptx_device,
|
2012-10-02 01:01:31 +08:00
|
|
|
kw_spir_kernel, kw_spir_func,
|
2013-07-12 14:02:35 +08:00
|
|
|
kw_x86_64_sysvcc, kw_x86_64_win64cc,
|
2013-11-09 07:28:16 +08:00
|
|
|
kw_webkit_jscc, kw_anyregcc,
|
2014-01-18 03:47:03 +08:00
|
|
|
kw_preserve_mostcc, kw_preserve_allcc,
|
2014-12-02 05:04:44 +08:00
|
|
|
kw_ghccc,
|
2015-12-21 22:07:14 +08:00
|
|
|
kw_x86_intrcc,
|
HHVM calling conventions.
HHVM calling convention, hhvmcc, is used by HHVM JIT for
functions in translated cache. We currently support LLVM back end to
generate code for X86-64 and may support other architectures in the
future.
In HHVM calling convention any GP register could be used to pass and
return values, with the exception of R12 which is reserved for
thread-local area and is callee-saved. Other than R12, we always
pass RBX and RBP as args, which are our virtual machine's stack pointer
and frame pointer respectively.
When we enter translation cache via hhvmcc function, we expect
the stack to be aligned at 16 bytes, i.e. skewed by 8 bytes as opposed
to standard ABI alignment. This affects stack object alignment and stack
adjustments for function calls.
One extra calling convention, hhvm_ccc, is used to call C++ helpers from
HHVM's translation cache. It is almost identical to standard C calling
convention with an exception of first argument which is passed in RBP
(before we use RDI, RSI, etc.)
Differential Revision: http://reviews.llvm.org/D12681
llvm-svn: 248832
2015-09-30 06:09:16 +08:00
|
|
|
kw_hhvmcc, kw_hhvm_ccc,
|
2015-12-05 01:40:13 +08:00
|
|
|
kw_cxx_fast_tlscc,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2013-02-06 14:52:58 +08:00
|
|
|
// Attributes:
|
|
|
|
kw_attributes,
|
|
|
|
kw_alwaysinline,
|
2015-07-11 18:30:36 +08:00
|
|
|
kw_argmemonly,
|
2013-02-26 14:58:09 +08:00
|
|
|
kw_sanitize_address,
|
2013-06-27 08:25:01 +08:00
|
|
|
kw_builtin,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_byval,
|
2013-12-19 10:14:12 +08:00
|
|
|
kw_inalloca,
|
2013-05-24 20:26:52 +08:00
|
|
|
kw_cold,
|
2015-05-27 07:48:40 +08:00
|
|
|
kw_convergent,
|
2014-07-18 23:51:28 +08:00
|
|
|
kw_dereferenceable,
|
2015-04-17 04:29:50 +08:00
|
|
|
kw_dereferenceable_or_null,
|
2015-12-17 00:16:19 +08:00
|
|
|
kw_inaccessiblememonly,
|
|
|
|
kw_inaccessiblemem_or_argmemonly,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_inlinehint,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_inreg,
|
2014-06-06 03:29:43 +08:00
|
|
|
kw_jumptable,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_minsize,
|
|
|
|
kw_naked,
|
|
|
|
kw_nest,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_noalias,
|
2013-02-22 08:12:35 +08:00
|
|
|
kw_nobuiltin,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_nocapture,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_noduplicate,
|
|
|
|
kw_noimplicitfloat,
|
|
|
|
kw_noinline,
|
2015-11-06 18:32:53 +08:00
|
|
|
kw_norecurse,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_nonlazybind,
|
2014-05-20 09:23:40 +08:00
|
|
|
kw_nonnull,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_noredzone,
|
|
|
|
kw_noreturn,
|
|
|
|
kw_nounwind,
|
2013-08-23 19:53:55 +08:00
|
|
|
kw_optnone,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_optsize,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_readnone,
|
|
|
|
kw_readonly,
|
2013-04-20 13:14:40 +08:00
|
|
|
kw_returned,
|
2011-10-03 22:45:37 +08:00
|
|
|
kw_returns_twice,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_signext,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_ssp,
|
|
|
|
kw_sspreq,
|
2013-01-23 14:41:41 +08:00
|
|
|
kw_sspstrong,
|
Protection against stack-based memory corruption errors using SafeStack
This patch adds the safe stack instrumentation pass to LLVM, which separates
the program stack into a safe stack, which stores return addresses, register
spills, and local variables that are statically verified to be accessed
in a safe way, and the unsafe stack, which stores everything else. Such
separation makes it much harder for an attacker to corrupt objects on the
safe stack, including function pointers stored in spilled registers and
return addresses. You can find more information about the safe stack, as
well as other parts of or control-flow hijack protection technique in our
OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf)
and our project website (http://levee.epfl.ch).
The overhead of our implementation of the safe stack is very close to zero
(0.01% on the Phoronix benchmarks). This is lower than the overhead of
stack cookies, which are supported by LLVM and are commonly used today,
yet the security guarantees of the safe stack are strictly stronger than
stack cookies. In some cases, the safe stack improves performance due to
better cache locality.
Our current implementation of the safe stack is stable and robust, we
used it to recompile multiple projects on Linux including Chromium, and
we also recompiled the entire FreeBSD user-space system and more than 100
packages. We ran unit tests on the FreeBSD system and many of the packages
and observed no errors caused by the safe stack. The safe stack is also fully
binary compatible with non-instrumented code and can be applied to parts of
a program selectively.
This patch is our implementation of the safe stack on top of LLVM. The
patches make the following changes:
- Add the safestack function attribute, similar to the ssp, sspstrong and
sspreq attributes.
- Add the SafeStack instrumentation pass that applies the safe stack to all
functions that have the safestack attribute. This pass moves all unsafe local
variables to the unsafe stack with a separate stack pointer, whereas all
safe variables remain on the regular stack that is managed by LLVM as usual.
- Invoke the pass as the last stage before code generation (at the same time
the existing cookie-based stack protector pass is invoked).
- Add unit tests for the safe stack.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6094
llvm-svn: 239761
2015-06-16 05:07:11 +08:00
|
|
|
kw_safestack,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_sret,
|
2013-02-26 14:58:09 +08:00
|
|
|
kw_sanitize_thread,
|
|
|
|
kw_sanitize_memory,
|
2013-02-06 14:52:58 +08:00
|
|
|
kw_uwtable,
|
|
|
|
kw_zeroext,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_type,
|
|
|
|
kw_opaque,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
kw_comdat,
|
|
|
|
|
|
|
|
// Comdat types
|
|
|
|
kw_any,
|
|
|
|
kw_exactmatch,
|
|
|
|
kw_largest,
|
|
|
|
kw_noduplicates,
|
|
|
|
kw_samesize,
|
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_eq, kw_ne, kw_slt, kw_sgt, kw_sle, kw_sge, kw_ult, kw_ugt, kw_ule,
|
|
|
|
kw_uge, kw_oeq, kw_one, kw_olt, kw_ogt, kw_ole, kw_oge, kw_ord, kw_uno,
|
|
|
|
kw_ueq, kw_une,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2011-07-29 05:48:00 +08:00
|
|
|
// atomicrmw operations that aren't also instruction keywords.
|
|
|
|
kw_xchg, kw_nand, kw_max, kw_min, kw_umax, kw_umin,
|
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// Instruction Opcodes (Opcode in UIntVal).
|
2009-06-05 06:49:04 +08:00
|
|
|
kw_add, kw_fadd, kw_sub, kw_fsub, kw_mul, kw_fmul,
|
|
|
|
kw_udiv, kw_sdiv, kw_fdiv,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_urem, kw_srem, kw_frem, kw_shl, kw_lshr, kw_ashr,
|
2009-07-08 11:04:38 +08:00
|
|
|
kw_and, kw_or, kw_xor, kw_icmp, kw_fcmp,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_phi, kw_call,
|
|
|
|
kw_trunc, kw_zext, kw_sext, kw_fptrunc, kw_fpext, kw_uitofp, kw_sitofp,
|
|
|
|
kw_fptoui, kw_fptosi, kw_inttoptr, kw_ptrtoint, kw_bitcast,
|
2013-11-15 09:34:59 +08:00
|
|
|
kw_addrspacecast,
|
2009-01-02 15:01:27 +08:00
|
|
|
kw_select, kw_va_arg,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2011-08-13 04:24:12 +08:00
|
|
|
kw_landingpad, kw_personality, kw_cleanup, kw_catch, kw_filter,
|
|
|
|
|
2012-02-07 05:02:43 +08:00
|
|
|
kw_ret, kw_br, kw_switch, kw_indirectbr, kw_invoke, kw_resume,
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
kw_unreachable, kw_cleanupret, kw_catchswitch, kw_catchret, kw_catchpad,
|
2015-12-15 02:34:23 +08:00
|
|
|
kw_cleanuppad,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2011-07-29 05:48:00 +08:00
|
|
|
kw_alloca, kw_load, kw_store, kw_fence, kw_cmpxchg, kw_atomicrmw,
|
|
|
|
kw_getelementptr,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2011-06-17 14:57:15 +08:00
|
|
|
kw_extractelement, kw_insertelement, kw_shufflevector,
|
2009-10-28 11:39:23 +08:00
|
|
|
kw_extractvalue, kw_insertvalue, kw_blockaddress,
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2015-01-09 06:38:29 +08:00
|
|
|
// Metadata types.
|
|
|
|
kw_distinct,
|
|
|
|
|
2014-08-20 05:30:15 +08:00
|
|
|
// Use-list order directives.
|
|
|
|
kw_uselistorder, kw_uselistorder_bb,
|
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// Unsigned Valued tokens (UIntVal).
|
|
|
|
GlobalID, // @42
|
|
|
|
LocalVarID, // %42
|
2013-02-06 14:52:58 +08:00
|
|
|
AttrGrpID, // #42
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// String valued tokens (StrVal).
|
|
|
|
LabelStr, // foo:
|
|
|
|
GlobalVar, // @foo @"foo"
|
2014-06-28 02:19:56 +08:00
|
|
|
ComdatVar, // $foo
|
2009-01-02 15:01:27 +08:00
|
|
|
LocalVar, // %foo %"foo"
|
2009-12-30 13:02:06 +08:00
|
|
|
MetadataVar, // !foo
|
2009-01-02 15:01:27 +08:00
|
|
|
StringConstant, // "foo"
|
2015-02-13 09:42:09 +08:00
|
|
|
DwarfTag, // DW_TAG_foo
|
|
|
|
DwarfAttEncoding, // DW_ATE_foo
|
|
|
|
DwarfVirtuality, // DW_VIRTUALITY_foo
|
|
|
|
DwarfLang, // DW_LANG_foo
|
|
|
|
DwarfOp, // DW_OP_foo
|
2015-02-21 09:02:18 +08:00
|
|
|
DIFlag, // DIFlagFoo
|
2015-12-10 20:56:35 +08:00
|
|
|
DwarfMacinfo, // DW_MACINFO_foo
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// Type valued tokens (TyVal).
|
2009-01-03 06:46:48 +08:00
|
|
|
Type,
|
|
|
|
|
Revert r136253, r136263, r136269, r136313, r136325, r136326, r136329, r136338,
r136339, r136341, r136369, r136387, r136392, r136396, r136429, r136430, r136444,
r136445, r136446, r136253 pending review.
llvm-svn: 136556
2011-07-30 13:42:50 +08:00
|
|
|
APFloat, // APFloatVal
|
|
|
|
APSInt // APSInt
|
2009-01-02 15:01:27 +08:00
|
|
|
};
|
|
|
|
} // end namespace lltok
|
|
|
|
} // end namespace llvm
|
|
|
|
|
|
|
|
#endif
|