maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/AsmParser/LLToken.h

383 lines
6.0 KiB
C
Raw Normal View History

Reimplement the old and horrible bison parser for .ll files with a nice and clean recursive descent parser. This change has a couple of ramifications: 1. The parser code is about 400 lines shorter (in what we maintain, not including what is autogenerated). 2. The code should be significantly faster than the old code because we don't have to work around bison's poor handling of datatypes with ctors/dtors. This also makes the code much more resistant to memory leaks. 3. We now get caret diagnostics from the .ll parser, woo. 4. The actual diagnostics emited from the parser are completely different so a bunch of testcases had to be updated. 5. I now disallow "%ty = type opaque %ty = type i32". There was no good reason to support this, it was just an accident of the old implementation. I have no reason to think that anyone is actually using this. 6. The syntax for sticking a global variable has changed to make it unambiguous. I don't think anyone is depending on this since only clang supports this and it is not solid yet, so I'm not worried about anything breaking. 7. This gets rid of the last use of bison, and along with it the .cvs files. I'll prune this from the makefiles as a subsequent commit. There are a few minor cleanups that can be done after this commit (suggestions welcome!) but this passes dejagnu testing and is ready for its time in the limelight. llvm-svn: 61558
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.
//
//===----------------------------------------------------------------------===//
Canonicalize header guards into a common format. Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
2014-08-14 00:26:38 +08:00
#ifndef LLVM_LIB_ASMPARSER_LLTOKEN_H
#define LLVM_LIB_ASMPARSER_LLTOKEN_H
Reimplement the old and horrible bison parser for .ll files with a nice and clean recursive descent parser. This change has a couple of ramifications: 1. The parser code is about 400 lines shorter (in what we maintain, not including what is autogenerated). 2. The code should be significantly faster than the old code because we don't have to work around bison's poor handling of datatypes with ctors/dtors. This also makes the code much more resistant to memory leaks. 3. We now get caret diagnostics from the .ll parser, woo. 4. The actual diagnostics emited from the parser are completely different so a bunch of testcases had to be updated. 5. I now disallow "%ty = type opaque %ty = type i32". There was no good reason to support this, it was just an accident of the old implementation. I have no reason to think that anyone is actually using this. 6. The syntax for sticking a global variable has changed to make it unambiguous. I don't think anyone is depending on this since only clang supports this and it is not solid yet, so I'm not worried about anything breaking. 7. This gets rid of the last use of bison, and along with it the .cvs files. I'll prune this from the makefiles as a subsequent commit. There are a few minor cleanups that can be done after this commit (suggestions welcome!) but this passes dejagnu testing and is ready for its time in the limelight. llvm-svn: 61558
2009-01-02 15:01:27 +08:00
namespace llvm {
namespace lltok {
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
enum Kind {
// Markers
Eof,
Error,
// Tokens with no info.
dotdotdot, // ...
equal,
comma, // = ,
star, // *
lsquare,
rsquare, // [ ]
lbrace,
rbrace, // { }
less,
greater, // < >
lparen,
rparen, // ( )
exclaim, // !
bar, // |
kw_x,
kw_true,
kw_false,
kw_declare,
kw_define,
kw_global,
kw_constant,
Represent runtime preemption in the IR. Currently we do not represent runtime preemption in the IR, which has several drawbacks: 1) The semantics of GlobalValues differ depending on the object file format you are targeting (as well as the relocation-model and -fPIE value). 2) We have no way of disabling inlining of run time interposable functions, since in the IR we only know if a function is link-time interposable. Because of this llvm cannot support elf-interposition semantics. 3) In LTO builds of executables we will have extra knowledge that a symbol resolved to a local definition and can't be preemptable, but have no way to propagate that knowledge through the compiler. This patch adds preemptability specifiers to the IR with the following meaning: dso_local --> means the compiler may assume the symbol will resolve to a definition within the current linkage unit and the symbol may be accessed directly even if the definition is not within this compilation unit. dso_preemptable --> means that the compiler must assume the GlobalValue may be replaced with a definition from outside the current linkage unit at runtime. To ease transitioning dso_preemptable is treated as a 'default' in that low-level codegen will still do the same checks it did previously to see if a symbol should be accessed indirectly. Eventually when IR producers emit the specifiers on all Globalvalues we can change dso_preemptable to mean 'always access indirectly', and remove the current logic. Differential Revision: https://reviews.llvm.org/D20217 llvm-svn: 316668
2017-10-26 23:00:26 +08:00
kw_dso_local,
kw_dso_preemptable,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_private,
kw_internal,
kw_linkonce,
kw_linkonce_odr,
kw_weak, // Used as a linkage, and a modifier for "cmpxchg".
kw_weak_odr,
kw_appending,
kw_dllimport,
kw_dllexport,
kw_common,
kw_available_externally,
kw_default,
kw_hidden,
kw_protected,
kw_unnamed_addr,
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
kw_local_unnamed_addr,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_externally_initialized,
kw_extern_weak,
kw_external,
kw_thread_local,
kw_localdynamic,
kw_initialexec,
kw_localexec,
kw_zeroinitializer,
kw_undef,
kw_null,
kw_none,
kw_to,
kw_caller,
kw_within,
kw_from,
kw_tail,
kw_musttail,
kw_notail,
kw_target,
kw_triple,
kw_source_filename,
kw_unwind,
kw_deplibs, // FIXME: Remove in 4.0
kw_datalayout,
kw_volatile,
kw_atomic,
kw_unordered,
kw_monotonic,
kw_acquire,
kw_release,
kw_acq_rel,
kw_seq_cst,
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
kw_syncscope,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_nnan,
kw_ninf,
kw_nsz,
kw_arcp,
[IR] Add AllowContract to FastMathFlags -ffp-contract=fast does not currently work with LTO because it's passed as a TargetOption to the backend rather than in the IR. This adds it to FastMathFlags. This is toward fixing PR25721 Differential Revision: https://reviews.llvm.org/D31164 llvm-svn: 298939
2017-03-29 04:11:52 +08:00
kw_contract,
[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html and again more recently: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html ...this is a step in cleaning up our fast-math-flags implementation in IR to better match the capabilities of both clang's user-visible flags and the backend's flags for SDNode. As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic reassociation - 'AllowReassoc'. We're also adding a bit to allow approximations for library functions called 'ApproxFunc' (this was initially proposed as 'libm' or similar). ...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), but that's apparently already used for other purposes. Also, I don't think we can just add a field to FPMathOperator because Operator is not intended to be instantiated. We'll defer movement of FMF to another day. We keep the 'fast' keyword. I thought about removing that, but seeing IR like this: %f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2 ...made me think we want to keep the shortcut synonym. Finally, this change is binary incompatible with existing IR as seen in the compatibility tests. This statement: "Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR." ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ) ...provides the flexibility we want to make this change without requiring a new IR version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will fail to optimize some previously 'fast' code because it's no longer recognized as 'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'. Note: an inter-dependent clang commit to use the new API name should closely follow commit. Differential Revision: https://reviews.llvm.org/D39304 llvm-svn: 317488
2017-11-07 00:27:15 +08:00
kw_reassoc,
kw_afn,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_fast,
kw_nuw,
kw_nsw,
kw_exact,
kw_inbounds,
IR: Introduce inrange attribute on getelementptr indices. If the inrange keyword is present before any index, loading from or storing to any pointer derived from the getelementptr has undefined behavior if the load or store would access memory outside of the bounds of the element selected by the index marked as inrange. This can be used, e.g. for alias analysis or to split globals at element boundaries where beneficial. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html Differential Revision: https://reviews.llvm.org/D22793 llvm-svn: 286514
2016-11-11 06:34:55 +08:00
kw_inrange,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_align,
kw_addrspace,
kw_section,
kw_alias,
kw_ifunc,
kw_module,
kw_asm,
kw_sideeffect,
kw_alignstack,
kw_inteldialect,
kw_gc,
kw_prefix,
kw_prologue,
kw_c,
kw_cc,
kw_ccc,
kw_fastcc,
kw_coldcc,
kw_intel_ocl_bicc,
kw_x86_stdcallcc,
kw_x86_fastcallcc,
kw_x86_thiscallcc,
kw_x86_vectorcallcc,
[X86] Basic additions to support RegCall Calling Convention. The Register Calling Convention (RegCall) was introduced by Intel to optimize parameter transfer on function call. This calling convention ensures that as many values as possible are passed or returned in registers. This commit presents the basic additions to LLVM CodeGen in order to support RegCall in X86. Differential Revision: http://reviews.llvm.org/D25022 llvm-svn: 284108
2016-10-13 15:53:43 +08:00
kw_x86_regcallcc,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_arm_apcscc,
kw_arm_aapcscc,
kw_arm_aapcs_vfpcc,
kw_msp430_intrcc,
kw_avr_intrcc,
kw_avr_signalcc,
kw_ptx_kernel,
kw_ptx_device,
kw_spir_kernel,
kw_spir_func,
kw_x86_64_sysvcc,
[AArch64] Extend CallingConv::X86_64_Win64 to AArch64 as well Rename the enum value from X86_64_Win64 to plain Win64. The symbol exposed in the textual IR is changed from 'x86_64_win64cc' to 'win64cc', but the numeric value is kept, keeping support for old bitcode. Differential Revision: https://reviews.llvm.org/D34474 llvm-svn: 308208
2017-07-18 04:05:19 +08:00
kw_win64cc,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_webkit_jscc,
kw_anyregcc,
kw_swiftcc,
kw_preserve_mostcc,
kw_preserve_allcc,
kw_ghccc,
kw_x86_intrcc,
kw_hhvmcc,
kw_hhvm_ccc,
kw_cxx_fast_tlscc,
kw_amdgpu_vs,
[AMDGPU] calling conventions for AMDPAL OS type Summary: This commit adds comments on how the AMDPAL OS type overloads the existing AMDGPU_ calling conventions used by Mesa, and adds a couple of new ones. Reviewers: arsenm, nhaehnle, dstuttard Subscribers: mehdi_amini, kzhuravl, wdng, yaxunl, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D37752 llvm-svn: 314502
2017-09-29 17:51:22 +08:00
kw_amdgpu_ls,
AMDGPU: Add AMDGPU_HS calling convention Reviewers: arsenm, nhaehnle Subscribers: mehdi_amini, kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye Differential Revision: https://reviews.llvm.org/D32644 llvm-svn: 301930
2017-05-02 23:41:10 +08:00
kw_amdgpu_hs,
[AMDGPU] calling conventions for AMDPAL OS type Summary: This commit adds comments on how the AMDPAL OS type overloads the existing AMDGPU_ calling conventions used by Mesa, and adds a couple of new ones. Reviewers: arsenm, nhaehnle, dstuttard Subscribers: mehdi_amini, kzhuravl, wdng, yaxunl, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D37752 llvm-svn: 314502
2017-09-29 17:51:22 +08:00
kw_amdgpu_es,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_amdgpu_gs,
kw_amdgpu_ps,
kw_amdgpu_cs,
kw_amdgpu_kernel,
// Attributes:
kw_attributes,
kw_allocsize,
kw_alwaysinline,
kw_argmemonly,
kw_sanitize_address,
Hardware-assisted AddressSanitizer (llvm part). Summary: This is LLVM instrumentation for the new HWASan tool. It is basically a stripped down copy of ASan at this point, w/o stack or global support. Instrumenation adds a global constructor + runtime callbacks for every load and store. HWASan comes with its own IR attribute. A brief design document can be found in clang/docs/HardwareAssistedAddressSanitizerDesign.rst (submitted earlier). Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, mehdi_amini, mgorny, javed.absar, eraman, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D40932 llvm-svn: 320217
2017-12-09 08:21:41 +08:00
kw_sanitize_hwaddress,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_builtin,
kw_byval,
kw_inalloca,
kw_cold,
kw_convergent,
kw_dereferenceable,
kw_dereferenceable_or_null,
kw_inaccessiblememonly,
kw_inaccessiblemem_or_argmemonly,
kw_inlinehint,
kw_inreg,
kw_jumptable,
kw_minsize,
kw_naked,
kw_nest,
kw_noalias,
kw_nobuiltin,
kw_nocapture,
kw_noduplicate,
kw_noimplicitfloat,
kw_noinline,
kw_norecurse,
kw_nonlazybind,
kw_nonnull,
kw_noredzone,
kw_noreturn,
[X86] Added support for nocf_check attribute for indirect Branch Tracking X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET). IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp. The `nocf_check` attribute has two roles in the context of X86 IBT technology: 1. Appertains to a function - do not add ENDBR instruction at the beginning of the function. 2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction. This patch implements `nocf_check` context for Indirect Branch Tracking. It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks. Differential Revision: https://reviews.llvm.org/D41879 llvm-svn: 327767
2018-03-17 21:29:46 +08:00
kw_nocf_check,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_nounwind,
[SimplifyCFG] Create attribute for fuzzing-specific optimizations. Summary: When building with libFuzzer, converting control flow to selects or obscuring the original operands of CMPs reduces the effectiveness of libFuzzer's heuristics. This patch provides an attribute to disable or modify certain optimizations for optimal fuzzing signal. Provides a less aggressive alternative to https://reviews.llvm.org/D44057. Reviewers: vitalybuka, davide, arsenm, hfinkel Reviewed By: vitalybuka Subscribers: junbuml, mehdi_amini, wdng, javed.absar, hiraditya, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D44232 llvm-svn: 328214
2018-03-23 01:07:51 +08:00
kw_optforfuzzing,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_optnone,
kw_optsize,
kw_readnone,
kw_readonly,
kw_returned,
kw_returns_twice,
kw_signext,
Add speculatable function attribute This attribute tells the optimizer that the function may be speculated. Patch by Tom Stellard llvm-svn: 301680
2017-04-29 04:25:27 +08:00
kw_speculatable,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_ssp,
kw_sspreq,
kw_sspstrong,
kw_safestack,
Add the ShadowCallStack attribute Summary: Introduce the ShadowCallStack function attribute. It's added to functions compiled with -fsanitize=shadow-call-stack in order to mark functions to be instrumented by a ShadowCallStack pass to be submitted in a separate change. Reviewers: pcc, kcc, kubamracek Reviewed By: pcc, kcc Subscribers: cryptoad, mehdi_amini, javed.absar, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D44800 llvm-svn: 329108
2018-04-04 04:10:40 +08:00
kw_shadowcallstack,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_sret,
kw_sanitize_thread,
kw_sanitize_memory,
Add strictfp attribute to prevent unwanted optimizations of libm calls Differential Revision: https://reviews.llvm.org/D34163 llvm-svn: 310885
2017-08-15 05:15:13 +08:00
kw_strictfp,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_swifterror,
kw_swiftself,
kw_uwtable,
Add writeonly IR attribute Summary: This complements the earlier addition of IntrWriteMem and IntrWriteArgMem LLVM intrinsic properties, see D18291. Also start using the attribute for memset, memcpy, and memmove intrinsics, and remove their special-casing in BasicAliasAnalysis. Reviewers: reames, joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18714 llvm-svn: 274485
2016-07-04 16:01:29 +08:00
kw_writeonly,
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
kw_zeroext,
kw_type,
kw_opaque,
kw_comdat,
// Comdat types
kw_any,
kw_exactmatch,
kw_largest,
kw_noduplicates,
kw_samesize,
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,
// atomicrmw operations that aren't also instruction keywords.
kw_xchg,
kw_nand,
kw_max,
kw_min,
kw_umax,
kw_umin,
// Instruction Opcodes (Opcode in UIntVal).
kw_add,
kw_fadd,
kw_sub,
kw_fsub,
kw_mul,
kw_fmul,
kw_udiv,
kw_sdiv,
kw_fdiv,
kw_urem,
kw_srem,
kw_frem,
kw_shl,
kw_lshr,
kw_ashr,
kw_and,
kw_or,
kw_xor,
kw_icmp,
kw_fcmp,
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,
kw_addrspacecast,
kw_select,
kw_va_arg,
kw_landingpad,
kw_personality,
kw_cleanup,
kw_catch,
kw_filter,
kw_ret,
kw_br,
kw_switch,
kw_indirectbr,
kw_invoke,
kw_resume,
kw_unreachable,
kw_cleanupret,
kw_catchswitch,
kw_catchret,
kw_catchpad,
kw_cleanuppad,
kw_alloca,
kw_load,
kw_store,
kw_fence,
kw_cmpxchg,
kw_atomicrmw,
kw_getelementptr,
kw_extractelement,
kw_insertelement,
kw_shufflevector,
kw_extractvalue,
kw_insertvalue,
kw_blockaddress,
// Metadata types.
kw_distinct,
// Use-list order directives.
kw_uselistorder,
kw_uselistorder_bb,
// Unsigned Valued tokens (UIntVal).
GlobalID, // @42
LocalVarID, // %42
AttrGrpID, // #42
// String valued tokens (StrVal).
LabelStr, // foo:
GlobalVar, // @foo @"foo"
ComdatVar, // $foo
LocalVar, // %foo %"foo"
MetadataVar, // !foo
StringConstant, // "foo"
DwarfTag, // DW_TAG_foo
DwarfAttEncoding, // DW_ATE_foo
DwarfVirtuality, // DW_VIRTUALITY_foo
DwarfLang, // DW_LANG_foo
[DebugInfo] Add calling convention support for DWARF and CodeView Summary: Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If it is present and non-zero, the backend will emit it as a DW_AT_calling_convention attribute. On the CodeView side, we translate it to the appropriate enum for the LF_PROCEDURE record. I added a new LLVM vendor specific enum to the list of DWARF calling conventions. DWARF does not appear to attempt to standardize these, so I assume it's OK to do this until we coordinate with GCC on how to emit vectorcall convention functions. Reviewers: dexonsmith, majnemer, aaboud, amccarth Subscribers: mehdi_amini, llvm-commits Differential Revision: http://reviews.llvm.org/D21114 llvm-svn: 272197
2016-06-09 04:34:29 +08:00
DwarfCC, // DW_CC_foo
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
EmissionKind, // lineTablesOnly
DwarfOp, // DW_OP_foo
DIFlag, // DIFlagFoo
DwarfMacinfo, // DW_MACINFO_foo
[DebugInfo] Added support for Checksum debug info feature. Differential Revision: https://reviews.llvm.org/D27642 llvm-svn: 290514
2016-12-25 18:12:09 +08:00
ChecksumKind, // CSK_foo
clang-format LLToken.h. Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-11 20:07:32 +08:00
// Type valued tokens (TyVal).
Type,
APFloat, // APFloatVal
APSInt // APSInt
};
Reimplement the old and horrible bison parser for .ll files with a nice and clean recursive descent parser. This change has a couple of ramifications: 1. The parser code is about 400 lines shorter (in what we maintain, not including what is autogenerated). 2. The code should be significantly faster than the old code because we don't have to work around bison's poor handling of datatypes with ctors/dtors. This also makes the code much more resistant to memory leaks. 3. We now get caret diagnostics from the .ll parser, woo. 4. The actual diagnostics emited from the parser are completely different so a bunch of testcases had to be updated. 5. I now disallow "%ty = type opaque %ty = type i32". There was no good reason to support this, it was just an accident of the old implementation. I have no reason to think that anyone is actually using this. 6. The syntax for sticking a global variable has changed to make it unambiguous. I don't think anyone is depending on this since only clang supports this and it is not solid yet, so I'm not worried about anything breaking. 7. This gets rid of the last use of bison, and along with it the .cvs files. I'll prune this from the makefiles as a subsequent commit. There are a few minor cleanups that can be done after this commit (suggestions welcome!) but this passes dejagnu testing and is ready for its time in the limelight. llvm-svn: 61558
2009-01-02 15:01:27 +08:00
} // end namespace lltok
} // end namespace llvm
#endif