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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

494 lines
7.9 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++ -*-===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
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
//
//===----------------------------------------------------------------------===//
//
// 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, // |
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
colon, // :
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
Scalable Vector IR Type with further LTO fixes Reintroduces the scalable vector IR type from D32530, after it was reverted a couple of times due to increasing chromium LTO build times. This latest incarnation removes the walk over aggregate types from the verifier entirely, in favor of rejecting scalable vectors in the isValidElementType methods in ArrayType and StructType. This removes the 70% degradation observed with the second repro tarball from PR42210. Reviewers: thakis, hans, rengolin, sdesmalen Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D64079 llvm-svn: 365203
2019-07-05 20:48:16 +08:00
kw_vscale,
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_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,
Adding PoisonValue for representing poison value explicitly in IR Define ConstantData::PoisonValue. Add support for poison value to LLLexer/LLParser/BitcodeReader/BitcodeWriter. Add support for poison value to llvm-c interface. Add support for poison value to OCaml binding. Add m_Poison in PatternMatch. Differential Revision: https://reviews.llvm.org/D71126
2020-11-25 05:55:24 +08:00
kw_poison,
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_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,
Add IR support, ELF section and user documentation for partitioning feature. The partitioning feature was proposed here: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html This is mostly just documentation. The feature itself will be contributed in subsequent patches. Differential Revision: https://reviews.llvm.org/D60242 llvm-svn: 361923
2019-05-29 11:29:01 +08:00
kw_partition,
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_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,
Add Windows Control Flow Guard checks (/guard:cf). Summary: A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on indirect function calls, using either the check mechanism (X86, ARM, AArch64) or or the dispatch mechanism (X86-64). The check mechanism requires a new calling convention for the supported targets. The dispatch mechanism adds the target as an operand bundle, which is processed by SelectionDAG. Another pass (CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as required by /guard:cf. This feature is enabled using the `cfguard` CC1 option. Reviewers: thakis, rnk, theraven, pcc Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65761
2019-10-28 21:22:19 +08:00
kw_cfguard_checkcc,
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_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,
[AArch64] Add parsing of aarch64_vector_pcs attribute. This patch adds parsing support for the 'aarch64_vector_pcs' calling convention attribute to calls and function declarations. More information describing the vector ABI and procedure call standard can be found here: https://developer.arm.com/products/software-development-tools/\ hpc/arm-compiler-for-hpc/vector-function-abi Reviewers: t.p.northover, rnk, rengolin, javed.absar, thegameg, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D51477 llvm-svn: 342030
2018-09-12 16:54:06 +08:00
kw_aarch64_vector_pcs,
[AArch64][SVE] Spilling/filling of SVE callee-saves. Implement the spills/fills of callee-saved SVE registers using STR and LDR instructions. Also adds the `aarch64_sve_vector_pcs` attribute to specify the callee-saved registers to be used for functions that return SVE vectors or take SVE vectors as arguments. The callee-saved registers are vector registers z8-z23 and predicate registers p4-p15. The overal frame-layout with SVE will be as follows: +-------------+ | stack args | +-------------+ | Callee Saves| | X29, X30 | |-------------| <- FP | SVE Callee | < ////////////// | saved regs | < ////////////// | z23 | < ////////////// | : | < // SCALABLE // | z8 | < ////////////// | p15 | < /// STACK //// | : | < ////////////// | p4 | < //// AREA //// +-------------+ < ////////////// | : | < ////////////// | SVE locals | < ////////////// | : | < ////////////// +-------------+ |/////////////| alignment gap. | : | | Stack objs | | : | +-------------+ <- SP after call and frame-setup Reviewers: cameron.mcinally, efriedma, greened, thegameg, ostannard, rengolin Reviewed By: ostannard Differential Revision: https://reviews.llvm.org/D68996
2019-11-06 00:54:54 +08:00
kw_aarch64_sve_vector_pcs,
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_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,
[AMDGPU] Add amdgpu_gfx calling convention Add a calling convention called amdgpu_gfx for real function calls within graphics shaders. For the moment, this uses the same calling convention as other calls in amdgpu, with registers excluded for return address, stack pointer and stack buffer descriptor. Differential Revision: https://reviews.llvm.org/D88540
2020-09-16 20:38:54 +08:00
kw_amdgpu_gfx,
[X86] Add new calling convention that guarantees tail call optimization When the target option GuaranteedTailCallOpt is specified, calls with the fastcc calling convention will be transformed into tail calls if they are in tail position. This diff adds a new calling convention, tailcc, currently supported only on X86, which behaves the same way as fastcc, except that the GuaranteedTailCallOpt flag does not need to enabled in order to enable tail call optimization. Patch by Dwight Guth <dwight.guth@runtimeverification.com>! Reviewed By: lebedev.ri, paquette, rnk Differential Revision: https://reviews.llvm.org/D67855 llvm-svn: 373976
2019-10-08 06:28:58 +08:00
kw_tailcc,
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
// 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,
ARM MTE stack sanitizer. Add "memtag" sanitizer that detects and mitigates stack memory issues using armv8.5 Memory Tagging Extension. It is similar in principle to HWASan, which is a software implementation of the same idea, but there are enough differencies to warrant a new sanitizer type IMHO. It is also expected to have very different performance properties. The new sanitizer does not have a runtime library (it may grow one later, along with a "debugging" mode). Similar to SafeStack and StackProtector, the instrumentation pass (in a follow up change) will be inserted in all cases, but will only affect functions marked with the new sanitize_memtag attribute. Reviewers: pcc, hctim, vitalybuka, ostannard Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64169 llvm-svn: 366123
2019-07-16 04:02:23 +08:00
kw_sanitize_memtag,
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,
[LLVM] Accept `noundef` attribute in function definitions/calls The `noundef` attribute indicates an argument or return value which may never have an undef value representation. This patch allows LLVM to parse the attribute. Differential Revision: https://reviews.llvm.org/D83412
2020-07-09 01:22:48 +08:00
kw_noundef,
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_nobuiltin,
[clang][IR] Add support for leaf attribute This patch adds support for leaf attribute as an optimization hint in Clang/LLVM. Differential Revision: https://reviews.llvm.org/D90275
2020-12-15 05:56:11 +08:00
kw_nocallback,
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_nocapture,
kw_noduplicate,
Add, and infer, a nofree function attribute This patch adds a function attribute, nofree, to indicate that a function does not, directly or indirectly, call a memory-deallocation function (e.g., free, C++'s operator delete). Reviewers: jdoerfert Differential Revision: https://reviews.llvm.org/D49165 llvm-svn: 365336
2019-07-08 23:57:56 +08:00
kw_nofree,
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_noimplicitfloat,
kw_noinline,
kw_norecurse,
kw_nonlazybind,
Add nomerge function attribute to supress tail merge optimization in simplifyCFG We want to add a way to avoid merging identical calls so as to keep the separate debug-information for those calls. There is also an asan usecase where having this attribute would be beneficial to avoid alternative work-arounds. Here is the link to the feature request: https://bugs.llvm.org/show_bug.cgi?id=42783. `nomerge` is different from `noline`. `noinline` prevents function from inlining at callsites, but `nomerge` prevents multiple identical calls from being merged into one. This patch adds `nomerge` to disable the optimization in IR level. A followup patch will be needed to let backend understands `nomerge` and avoid tail merge at backend. Reviewed By: asbirlea, rnk Differential Revision: https://reviews.llvm.org/D78659
2020-05-13 05:07:50 +08:00
kw_nomerge,
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_nonnull,
Support for instrumenting only selected files or functions This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the sanitizer special case list format to select which files and functions to instrument, and relies on the new noprofile IR attribute to exclude functions from instrumentation. Differential Revision: https://reviews.llvm.org/D94820
2021-01-15 17:14:37 +08:00
kw_noprofile,
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_noredzone,
kw_noreturn,
[Attributor] Deduce "nosync" function attribute. Introduce and deduce "nosync" function attribute to indicate that a function does not synchronize with another thread in a way that other thread might free memory. Reviewers: jdoerfert, jfb, nhaehnle, arsenm Subscribers: wdng, hfinkel, nhaenhle, mehdi_amini, steven_wu, dexonsmith, arsenm, uenoku, hiraditya, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D62766 llvm-svn: 365830
2019-07-12 05:37:40 +08:00
kw_nosync,
[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,
[IR] Convert null-pointer-is-valid into an enum attribute The "null-pointer-is-valid" attribute needs to be checked by many pointer-related combines. To make the check more efficient, convert it from a string into an enum attribute. In the future, this attribute may be replaced with data layout properties. Differential Revision: https://reviews.llvm.org/D78862
2020-04-25 18:57:07 +08:00
kw_null_pointer_is_valid,
[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,
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
kw_preallocated,
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_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,
[x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
2018-09-04 20:38:00 +08:00
kw_speculative_load_hardening,
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,
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 21:53:30 +08:00
kw_vscale_range,
[Attr] Add "willreturn" function attribute This patch introduces a new function attribute, willreturn, to indicate that a call of this function will either exhibit undefined behavior or comes back and continues execution at a point in the existing call stack that includes the current invocation. This attribute guarantees that the function does not have any endless loops, endless recursion, or terminating functions like abort or exit. Patch by Hideto Ueno (@uenoku) Reviewers: jdoerfert Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62801 llvm-svn: 364555
2019-06-27 23:51:40 +08:00
kw_willreturn,
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,
IR: Add immarg attribute This indicates an intrinsic parameter is required to be a constant, and should not be replaced with a non-constant value. Add the attribute to all AMDGPU and generic intrinsics that comments indicate it should apply to. I scanned other target intrinsics, but I don't see any obvious comments indicating which arguments are intended to be only immediates. This breaks one questionable testcase for the autoupgrade. I'm unclear on whether the autoupgrade is supposed to really handle declarations which were never valid. The verifier fails because the attributes now refer to a parameter past the end of the argument list. llvm-svn: 355981
2019-03-13 05:02:54 +08:00
kw_immarg,
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
kw_byref,
[IR] Adds mustprogress as a LLVM IR attribute This adds the LLVM IR attribute `mustprogress` as defined in LangRef through D86233. This attribute will be applied to functions with in languages like C++ where forward progress is guaranteed. Functions without this attribute are not required to make progress. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D85393
2020-10-20 14:48:18 +08:00
kw_mustprogress,
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_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).
[IR] Add a dedicated FNeg IR Instruction The IEEE-754 Standard makes it clear that fneg(x) and fsub(-0.0, x) are two different operations. The former is a bitwise operation, while the latter is an arithmetic operation. This patch creates a dedicated FNeg IR Instruction to model that behavior. Differential Revision: https://reviews.llvm.org/D53877 llvm-svn: 346774
2018-11-14 02:15:47 +08:00
kw_fneg,
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_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,
Implementation of asm-goto support in LLVM This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
2019-02-09 04:48:56 +08:00
kw_callbr,
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_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,
[llvm][IR] Add dso_local_equivalent Constant The `dso_local_equivalent` constant is a wrapper for functions that represents a value which is functionally equivalent to the global passed to this. That is, if this accepts a function, calling this constant should have the same effects as calling the function directly. This could be a direct reference to the function, the `@plt` modifier on X86/AArch64, a thunk, or anything that's equivalent to the resolved function as a call target. When lowered, the returned address must have a constant offset at link time from some other symbol defined within the same binary. The address of this value is also insignificant. The name is leveraged from `dso_local` where use of a function or variable is resolved to a symbol in the same linkage unit. In this patch: - Addition of `dso_local_equivalent` and handling it - Update Constant::needsRelocation() to strip constant inbound GEPs and take advantage of `dso_local_equivalent` for relative references This is useful for the [Relative VTables C++ ABI](https://reviews.llvm.org/D72959) which makes vtables readonly. This works by replacing the dynamic relocations for function pointers in them with static relocations that represent the offset between the vtable and virtual functions. If a function is externally defined, `dso_local_equivalent` can be used as a generic wrapper for the function to still allow for this static offset calculation to be done. See [RFC](http://lists.llvm.org/pipermail/llvm-dev/2020-August/144469.html) for more details. Differential Revision: https://reviews.llvm.org/D77248
2020-04-02 06:25:04 +08:00
kw_dso_local_equivalent,
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
[IR] Redefine Freeze instruction Summary: This patch redefines freeze instruction from being UnaryOperator to a subclass of UnaryInstruction. ConstantExpr freeze is removed, as discussed in the previous review. FreezeOperator is not added because there's no ConstantExpr freeze. `freeze i8* null` test is added to `test/Bindings/llvm-c/freeze.ll` as well, because the null pointer-related bug in `tools/llvm-c/echo.cpp` is now fixed. InstVisitor has visitFreeze now because freeze is not unaryop anymore. Reviewers: whitequark, deadalnix, craig.topper, jdoerfert, lebedev.ri Reviewed By: craig.topper, lebedev.ri Subscribers: regehr, nlopes, mehdi_amini, hiraditya, steven_wu, dexonsmith, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69932
2019-11-07 00:17:49 +08:00
kw_freeze,
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
// Metadata types.
kw_distinct,
// Use-list order directives.
kw_uselistorder,
kw_uselistorder_bb,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
// Summary index keywords
kw_path,
kw_hash,
kw_gv,
kw_guid,
kw_name,
kw_summaries,
kw_flags,
[ThinLTO] Compute the basic block count across modules. Summary: Count the per-module number of basic blocks when the module summary is computed and sum them up during Thin LTO indexing. This is used to estimate the working set size under the partial sample PGO. This is split off of D79831. Reviewers: davidxl, espindola Subscribers: emaste, inglorion, hiraditya, MaskRay, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80403
2020-05-22 04:28:24 +08:00
kw_blockcount,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
kw_linkage,
[ThinLTO] Add Visibility bits to GlobalValueSummary::GVFlags Imported functions and variable get the visibility from the module supplying the definition. However, non-imported definitions do not get the visibility from (ELF) the most constraining visibility among all modules (Mach-O) the visibility of the prevailing definition. This patch * adds visibility bits to GlobalValueSummary::GVFlags * computes the result visibility and propagates it to all definitions Protected/hidden can imply dso_local which can enable some optimizations (this is stronger than GVFlags::DSOLocal because the implied dso_local can be leveraged for ELF -shared while default visibility dso_local has to be cleared for ELF -shared). Note: we don't have summaries for declarations, so for ELF if a declaration has the most constraining visibility, the result visibility may not be that one. Differential Revision: https://reviews.llvm.org/D92900
2021-01-28 02:43:51 +08:00
kw_visibility,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
kw_notEligibleToImport,
kw_live,
kw_dsoLocal,
[ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible Summary: We hit undefined references building with ThinLTO when one source file contained explicit instantiations of a template method (weak_odr) but there were also implicit instantiations in another file (linkonce_odr), and the latter was the prevailing copy. In this case the symbol was marked hidden when the prevailing linkonce_odr copy was promoted to weak_odr. It led to unsats when the resulting shared library was linked with other code that contained a reference (expecting to be resolved due to the explicit instantiation). Add a CanAutoHide flag to the GV summary to allow the thin link to identify when all copies are eligible for auto-hiding (because they were all originally linkonce_odr global unnamed addr), and only do the auto-hide in that case. Most of the changes here are due to plumbing the new flag through the bitcode and llvm assembly, and resulting test changes. I augmented the existing auto-hide test to check for this situation. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, dexonsmith, arphaman, dang, llvm-commits, steven_wu, wmi Tags: #llvm Differential Revision: https://reviews.llvm.org/D59709 llvm-svn: 360466
2019-05-11 04:08:24 +08:00
kw_canAutoHide,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
kw_function,
kw_insts,
kw_funcFlags,
kw_readNone,
kw_readOnly,
kw_noRecurse,
kw_returnDoesNotAlias,
[ThinLTO] Split NotEligibleToImport into legality and inlinability flags Summary: The NotEligibleToImport flag on the GlobalValueSummary was set if it isn't legal to import (e.g. because it references unpromotable locals) and when it can't be inlined (in which case importing is pointless). I split out the inlinable piece into a separate flag on the FunctionSummary (doesn't make sense for aliases or global variables), because in the future we may want to import for reasons other than inlining. Reviewers: davidxl Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D53345 llvm-svn: 346261
2018-11-07 03:41:35 +08:00
kw_noInline,
ThinLTO : Import always_inline functions irrespective of the threshold Summary: A user can force a function to be inlined by specifying the always_inline attribute. Currently, thinlto implementation is not aware of always_inline functions and does not guarantee import of such functions, which in turn can prevent inlining of such functions. Patch by Bharathi Seshadri <bseshadr@cisco.com> Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70014
2019-11-09 07:50:55 +08:00
kw_alwaysInline,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
kw_calls,
kw_callee,
[StackSafety] Add info into function summary Summary: This patch adds optional field into function summary, implements asm and bitcode serialization. YAML serialization is omitted and can be added later if needed. This patch includes this information into summary only if module contains at least one sanitize_memtag function. In a near future MTE is the user of the analysis. Later if needed we can provede more direct control on when information is included into summary. Reviewers: eugenis Subscribers: hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80908
2020-06-01 14:49:57 +08:00
kw_params,
kw_param,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
kw_hotness,
kw_unknown,
kw_hot,
kw_critical,
kw_relbf,
kw_variable,
[ThinLTO] Add summary entries for index-based WPD Summary: If LTOUnit splitting is disabled, the module summary analysis computes the summary information necessary to perform single implementation devirtualization during the thin link with the index and no IR. The information collected from the regular LTO IR in the current hybrid WPD algorithm is summarized, including: 1) For vtable definitions, record the function pointers and their offset within the vtable initializer (subsumes the information collected from IR by tryFindVirtualCallTargets). 2) A record for each type metadata summarizing the vtable definitions decorated with that metadata (subsumes the TypeIdentiferMap collected from IR). Also added are the necessary bitcode records, and the corresponding assembly support. The follow-on index-based WPD patch is D55153. Depends on D53890. Reviewers: pcc Subscribers: mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54815 llvm-svn: 364960
2019-07-03 03:38:02 +08:00
kw_vTableFuncs,
kw_virtFunc,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
kw_aliasee,
kw_refs,
kw_typeIdInfo,
kw_typeTests,
kw_typeTestAssumeVCalls,
kw_typeCheckedLoadVCalls,
kw_typeTestAssumeConstVCalls,
kw_typeCheckedLoadConstVCalls,
kw_vFuncId,
kw_offset,
kw_args,
kw_typeid,
[ThinLTO] Add summary entries for index-based WPD Summary: If LTOUnit splitting is disabled, the module summary analysis computes the summary information necessary to perform single implementation devirtualization during the thin link with the index and no IR. The information collected from the regular LTO IR in the current hybrid WPD algorithm is summarized, including: 1) For vtable definitions, record the function pointers and their offset within the vtable initializer (subsumes the information collected from IR by tryFindVirtualCallTargets). 2) A record for each type metadata summarizing the vtable definitions decorated with that metadata (subsumes the TypeIdentiferMap collected from IR). Also added are the necessary bitcode records, and the corresponding assembly support. The follow-on index-based WPD patch is D55153. Depends on D53890. Reviewers: pcc Subscribers: mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54815 llvm-svn: 364960
2019-07-03 03:38:02 +08:00
kw_typeidCompatibleVTable,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
kw_summary,
kw_typeTestRes,
kw_kind,
kw_unsat,
kw_byteArray,
kw_inline,
kw_single,
kw_allOnes,
kw_sizeM1BitWidth,
kw_alignLog2,
kw_sizeM1,
kw_bitMask,
kw_inlineBits,
[ThinLTO] Summarize vcall_visibility metadata Summary: Second patch in series to support Safe Whole Program Devirtualization Enablement, see RFC here: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137543.html Summarize vcall_visibility metadata in ThinLTO global variable summary. Depends on D71907. Reviewers: pcc, evgeny777, steven_wu Subscribers: mehdi_amini, Prazek, inglorion, hiraditya, dexonsmith, arphaman, ostannard, llvm-commits, cfe-commits, davidxl Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71911
2019-12-27 01:31:43 +08:00
kw_vcall_visibility,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
kw_wpdResolutions,
kw_wpdRes,
kw_indir,
kw_singleImpl,
kw_branchFunnel,
kw_singleImplName,
kw_resByArg,
kw_byArg,
kw_uniformRetVal,
kw_uniqueRetVal,
kw_virtualConstProp,
kw_info,
kw_byte,
kw_bit,
[ThinLTO] Assembly representation of ReadOnly attribute Differential revision: https://reviews.llvm.org/D54754 llvm-svn: 347489
2018-11-23 18:54:51 +08:00
kw_varFlags,
[ThinLTO] Parse module summary index from assembly Summary: Adds assembly parsing support for the module summary index (follow on to r333335 which added the assembly writing support). I added support to llvm-as to invoke the index parsing, so that it can create either a bitcode file with a Module and a per-module index, or a combined index without a Module. I will send follow on patches soon to do the following: - add support to tools such as llvm-lto2 to parse the per-module indexes from assembly instead of bitcode when testing the thin link. - verification support. Depends on D47844 and D47842. Reviewers: pcc, dexonsmith, mehdi_amini Subscribers: inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47905 llvm-svn: 335602
2018-06-26 21:56:49 +08:00
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
// Unsigned Valued tokens (UIntVal).
IR: Support parsing numeric block ids, and emit them in textual output. Just as as llvm IR supports explicitly specifying numeric value ids for instructions, and emits them by default in textual output, now do the same for blocks. This is a slightly incompatible change in the textual IR format. Previously, llvm would parse numeric labels as string names. E.g. define void @f() { br label %"55" 55: ret void } defined a label *named* "55", even without needing to be quoted, while the reference required quoting. Now, if you intend a block label which looks like a value number to be a name, you must quote it in the definition too (e.g. `"55":`). Previously, llvm would print nameless blocks only as a comment, and would omit it if there was no predecessor. This could cause confusion for readers of the IR, just as unnamed instructions did prior to the addition of "%5 = " syntax, back in 2008 (PR2480). Now, it will always print a label for an unnamed block, with the exception of the entry block. (IMO it may be better to print it for the entry-block as well. However, that requires updating many more tests.) Thus, the following is supported, and is the canonical printing: define i32 @f(i32, i32) { %3 = add i32 %0, %1 br label %4 4: ret i32 %3 } New test cases covering this behavior are added, and other tests updated as required. Differential Revision: https://reviews.llvm.org/D58548 llvm-svn: 356789
2019-03-23 02:27:13 +08:00
LabelID, // 42:
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
GlobalID, // @42
LocalVarID, // %42
AttrGrpID, // #42
[ThinLTO] Print module summary index to assembly Summary: Implements AsmWriter support for printing the module summary index to assembly with the format discussed in the RFC "LLVM Assembly format for ThinLTO Summary". Implements just enough of the parsing support to recognize and ignore the summary entries. As agreed in the RFC thread, this will be the behavior when assembling the IR. A follow on change will implement parsing/assembling of the summary entries for use by tools that currently build the summary index from bitcode. Reviewers: dexonsmith, pcc Subscribers: inglorion, eraman, steven_wu, dblaikie, llvm-commits Differential Revision: https://reviews.llvm.org/D46699 llvm-svn: 333335
2018-05-26 10:34:13 +08:00
SummaryID, // ^42
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
// 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
DebugInfo: Add metadata support for disabling DWARF pub sections In cases where the debugger load time is a worthwhile tradeoff (or less costly - such as loading from a DWP instead of a variety of DWOs (possibly over a high-latency/distributed filesystem)) against object file size, it can be reasonable to disable pubnames and corresponding gdb-index creation in the linker. A backend-flag version of this was implemented for NVPTX in D44385/r327994 - which was fine for NVPTX which wouldn't mix-and-match CUs. Now that it's going to be a user-facing option (likely powered by "-gno-pubnames", the same as GCC) it should be encoded in the DICompileUnit so it can vary per-CU. After this, likely the NVPTX support should be migrated to the metadata & the previous flag implementation should be removed. Reviewers: aprantl Differential Revision: https://reviews.llvm.org/D50213 llvm-svn: 339939
2018-08-17 05:29:55 +08:00
NameTableKind, // GNU
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
DwarfOp, // DW_OP_foo
DIFlag, // DIFlagFoo
[DebugInfo] IR/Bitcode changes for DISubprogram flags. Packing the flags into one bitcode word will save effort in adding new flags in the future. Differential Revision: https://reviews.llvm.org/D54755 llvm-svn: 347806
2018-11-29 05:14:32 +08:00
DISPFlag, // DISPFlagFoo
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
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