summaryrefslogtreecommitdiffstats
path: root/llvm/utils
Commit message (Collapse)AuthorAgeFilesLines
* [FileCheck] Remove implementation types from APIThomas Preud'homme2019-09-301-3/+2
| | | | | | | | | | | | | | | | | Summary: Remove use of FileCheckPatternContext and FileCheckString concrete types from FileCheck API to allow moving it and the other implementation only only declarations into a private header file. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68186 llvm-svn: 373211
* gn build: Merge r373202GN Sync Bot2019-09-302-0/+2
| | | | llvm-svn: 373204
* Revert "Reland "[utils] Implement the llvm-locstats tool""Djordje Todorovic2019-09-302-215/+0
| | | | | | This reverts commit rL373183. llvm-svn: 373200
* Reland "[utils] Implement the llvm-locstats tool"Djordje Todorovic2019-09-302-0/+215
| | | | | | | | | | | | | | | | The tool reports verbose output for the DWARF debug location coverage. The llvm-locstats for each variable or formal parameter DIE computes what percentage from the code section bytes, where it is in scope, it has location description. The line 0 shows the number (and the percentage) of DIEs with no location information, but the line 100 shows the number (and the percentage) of DIEs where there is location information in all code section bytes (where the variable or parameter is in the scope). The line 50..59 shows the number (and the percentage) of DIEs where the location information is in between 50 and 59 percentage of its scope covered. Differential Revision: https://reviews.llvm.org/D66526 llvm-svn: 373183
* gn build: (manually) merge r373082Nico Weber2019-09-274-71/+33
| | | | llvm-svn: 373086
* gn build: Merge r373083GN Sync Bot2019-09-272-0/+2
| | | | llvm-svn: 373085
* Reland "gn build: (manually) merge r373028"Nico Weber2019-09-274-0/+21
| | | | | | This relands r373029, reverted in 373033, because r373028 relanded in r373066. llvm-svn: 373070
* [UpdateTestChecks] Fix wildcard support on DOS promptsSimon Pilgrim2019-09-271-3/+3
| | | | | | D64572 / rL365818 changed the way that the file paths were collected, which meant we lost the file pattern expansion necessary when working with DOS command prompt llvm-svn: 373062
* Revert "gn build: (manually) merge r373028"Dmitri Gribenko2019-09-264-21/+0
| | | | | | This reverts commit r373029, which depends on r373028, which I reverted. llvm-svn: 373033
* gn build: (manually) merge r373028Nico Weber2019-09-264-0/+21
| | | | llvm-svn: 373029
* [NFC][emacs] remove out-of-date comment from tablegen-mode.elBob Haarman2019-09-261-2/+0
| | | | | | | | | | | | | | | | | | | | Summary: The syntax table was originally based on and attributed to jasmin.el, but was rewritten in r45192, so the comment that says the code comes from jasmin.el is no longer accurate. This change removes the comment, shortening the code a bit. Reviewers: MaskRay, lattner Reviewed By: MaskRay Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68042 llvm-svn: 373008
* DAGISelMatcherOpt - TGParser::ParseOperation - silence static analyzer ↵Simon Pilgrim2019-09-261-4/+5
| | | | | | | | cast_or_null<CheckTypeMatcher> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, replace with an null/isa assertion and cast<CheckTypeMatcher>. llvm-svn: 373001
* build_llvm_package.bat: Bootstrap with VS 2019Hans Wennborg2019-09-261-7/+7
| | | | llvm-svn: 372984
* [emacs] simplify and improve keyword highlighting in tablegen-mode.elBob Haarman2019-09-251-3/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: The keyword and type keyword matchers in tablegen-mode.el checked for space, newline, tab, or open paren after the regular expression that matches keywords (or type keywords, respectively). This is unnecessary, because those regular expressions already include word boundaries. This change removes the extra check. This also causes "def" in "def:" to be highlighted as a keyword, which was missed before. Reviewers: lattner, MaskRay Reviewed By: MaskRay Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68002 llvm-svn: 372904
* [gn build] Fix Python DeprecationWarningMarco Antognini2019-09-251-4/+10
| | | | | | | | | | | | | | | Summary: This fixes two issues: - DeprecationWarning: invalid escape sequence \` - ResourceWarning: unclosed file Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67753 llvm-svn: 372876
* gn build: (manually) merge r372843Nico Weber2019-09-251-0/+1
| | | | llvm-svn: 372850
* gn build: Merge r372841GN Sync Bot2019-09-252-0/+2
| | | | llvm-svn: 372842
* [tblgen] Disable Leak detection for ASan/GCC and LSan/LLVMKamil Rytarowski2019-09-241-4/+9
| | | | | | | | | | | | | | | | Summary: Add support for sanitizing TableGen.cpp with ASan/GCC and LSan/LLVM. Reviewers: fjricci, kcc, aaron.ballman, mgorny Reviewed By: fjricci Subscribers: jakubjelinek, llvm-commits, #llvm Tags: #llvm Differential Revision: https://reviews.llvm.org/D67908 llvm-svn: 372731
* gn build: Merge r372712GN Sync Bot2019-09-241-0/+1
| | | | llvm-svn: 372713
* gn build: Merge r372706GN Sync Bot2019-09-241-0/+1
| | | | llvm-svn: 372707
* Revert "[lit] Add -D__clang_analyzer__ to clang_analyze_cc1"Jan Korous2019-09-241-1/+1
| | | | | | This reverts commit 4185460f758b98ea5b898c04c179704756ca8f53. llvm-svn: 372686
* [lit] Add -D__clang_analyzer__ to clang_analyze_cc1Jan Korous2019-09-241-1/+1
| | | | | | Fixup after fbd13570b0d llvm-svn: 372682
* [TableGen] Emit OperandType enums for RegisterOperands/RegisterClassesAditya Nandakumar2019-09-231-7/+18
| | | | | | | | | | | | | | https://reviews.llvm.org/D66773 The OpTypes::OperandType was creating an enum for all records that inherit from Operand, but in reality there are operands for instructions that inherit from other types too. In particular, RegisterOperand and RegisterClass. This commit adds those types to the list of operand types that are tracked by the OperandType enum. Patch by: nlguillemot llvm-svn: 372641
* Cosmetic; don't use the magic constant 35 when HASH is more readable. This ↵Mark Murray2019-09-231-0/+1
| | | | | | | | | | | | | | | | matches other MCK__<THING>_* usage better. Summary: No functional change. This fixes a magic constant in MCK__*_... macros only. Reviewers: ostannard Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67840 llvm-svn: 372599
* gn build: Merge r372595GN Sync Bot2019-09-232-0/+2
| | | | llvm-svn: 372597
* gn build: Merge r372564GN Sync Bot2019-09-231-0/+1
| | | | llvm-svn: 372581
* Revert "Reland "[utils] Implement the llvm-locstats tool""Djordje Todorovic2019-09-232-215/+0
| | | | | | This reverts commit rL372554. llvm-svn: 372580
* Reland "[utils] Implement the llvm-locstats tool"Djordje Todorovic2019-09-232-0/+215
| | | | | | | | | | | | | | | | The tool reports verbose output for the DWARF debug location coverage. The llvm-locstats for each variable or formal parameter DIE computes what percentage from the code section bytes, where it is in scope, it has location description. The line 0 shows the number (and the percentage) of DIEs with no location information, but the line 100 shows the number (and the percentage) of DIEs where there is location information in all code section bytes (where the variable or parameter is in the scope). The line 50..59 shows the number (and the percentage) of DIEs where the location information is in between 50 and 59 percentage of its scope covered. Differential Revision: https://reviews.llvm.org/D66526 llvm-svn: 372554
* [X86][TableGen] Allow timm to appear in output patterns. Use it to remove ↵Craig Topper2019-09-221-0/+1
| | | | | | | | | | | | | | ConvertToTarget opcodes from the X86 isel table. We're now using a lot more TargetConstant nodes in SelectionDAG. But we were still telling isel to convert some of them to TargetConstants even though they already are. This is because isel emits a conversion anytime the output pattern has a an 'imm'. I guess for patterns in instructions we take the 'timm' from the 'set' pattern, but for Pat patterns with explcicit output we previously had to say 'imm' since 'timm' wasn't allowed in outputs. llvm-svn: 372525
* gn build: Friendlier error on invalid entries in llvm_targets_to_buildNico Weber2019-09-221-20/+27
| | | | llvm-svn: 372515
* gn build: consolidate "Nothing to do" branches in targets.gniNico Weber2019-09-221-19/+6
| | | | | | No behavior change. llvm-svn: 372512
* gn build: Add missing RISCV to llvm_targets_to_build="all"Nico Weber2019-09-221-0/+1
| | | | llvm-svn: 372506
* gn build: Add build files for llvm/lib/Target/AVRNico Weber2019-09-227-1/+185
| | | | | | Differential Revision: https://reviews.llvm.org/D67872 llvm-svn: 372505
* gn build: Merge r372445GN Sync Bot2019-09-211-0/+1
| | | | llvm-svn: 372446
* gn build: Merge r372396GN Sync Bot2019-09-201-0/+2
| | | | llvm-svn: 372397
* [IntrinsicEmitter] Add overloaded types for SVE intrinsics (Subdivide2 & ↵Kerry McLaughlin2019-09-201-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Subdivide4) Summary: Both match the type of another intrinsic parameter of a vector type, but where each element is subdivided to form a vector with more elements of a smaller type. Subdivide2Argument allows intrinsics such as the following to be defined: - declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 8 x i16>) Subdivide4Argument allows intrinsics such as: - declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 16 x i8>) Tests are included in follow up patches which add intrinsics using these types. Reviewers: sdesmalen, SjoerdMeijer, greened, rovka Reviewed By: sdesmalen Subscribers: rovka, tschuett, jdoerfert, cfe-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67549 llvm-svn: 372380
* gn build: Merge r372343GN Sync Bot2019-09-192-0/+2
| | | | llvm-svn: 372344
* Reapply r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"Matt Arsenault2019-09-191-1/+26
| | | | | | | | | This reverts r372314, reapplying r372285 and the commits which depend on it (r372286-r372293, and r372296-r372297) This was missing one switch to getTargetConstant in an untested case. llvm-svn: 372338
* [TableGen] Support encoding per-HwModeJames Molloy2019-09-196-38/+179
| | | | | | | | | | | | | | Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets to modify an instruction's encoding based on HwMode. When the EncodingInfos field is non-empty the Inst and Size fields of the Instruction are ignored and taken from EncodingInfos instead. As part of this promote getHwMode() from TargetSubtargetInfo to MCSubtargetInfo. This is NFC for all existing targets - new code is generated only if targets use EncodingByHwMode. llvm-svn: 372320
* Revert r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"Hans Wennborg2019-09-191-26/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This broke the Chromium build, causing it to fail with e.g. fatal error: error in backend: Cannot select: t362: v4i32 = X86ISD::VSHLI t392, Constant:i8<15> See llvm-commits thread of r372285 for details. This also reverts r372286, r372287, r372288, r372289, r372290, r372291, r372292, r372293, r372296, and r372297, which seemed to depend on the main commit. > Encode them directly as an imm argument to G_INTRINSIC*. > > Since now intrinsics can now define what parameters are required to be > immediates, avoid using registers for them. Intrinsics could > potentially want a constant that isn't a legal register type. Also, > since G_CONSTANT is subject to CSE and legalization, transforms could > potentially obscure the value (and create extra work for the > selector). The register bank of a G_CONSTANT is also meaningful, so > this could throw off future folding and legalization logic for AMDGPU. > > This will be much more convenient to work with than needing to call > getConstantVRegVal and checking if it may have failed for every > constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth > immarg operands, many of which need inspection during lowering. Having > to find the value in a register is going to add a lot of boilerplate > and waste compile time. > > SelectionDAG has always provided TargetConstant for constants which > should not be legalized or materialized in a register. The distinction > between Constant and TargetConstant was somewhat fuzzy, and there was > no automatic way to force usage of TargetConstant for certain > intrinsic parameters. They were both ultimately ConstantSDNode, and it > was inconsistently used. It was quite easy to mis-select an > instruction requiring an immediate. For SelectionDAG, start emitting > TargetConstant for these arguments, and using timm to match them. > > Most of the work here is to cleanup target handling of constants. Some > targets process intrinsics through intermediate custom nodes, which > need to preserve TargetConstant usage to match the intrinsic > expectation. Pattern inputs now need to distinguish whether a constant > is merely compatible with an operand or whether it is mandatory. > > The GlobalISelEmitter needs to treat timm as a special case of a leaf > node, simlar to MachineBasicBlock operands. This should also enable > handling of patterns for some G_* instructions with immediates, like > G_FENCE or G_EXTRACT. > > This does include a workaround for a crash in GlobalISelEmitter when > ARM tries to uses "imm" in an output with a "timm" pattern source. llvm-svn: 372314
* GlobalISel: Don't materialize immarg arguments to intrinsicsMatt Arsenault2019-09-191-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Encode them directly as an imm argument to G_INTRINSIC*. Since now intrinsics can now define what parameters are required to be immediates, avoid using registers for them. Intrinsics could potentially want a constant that isn't a legal register type. Also, since G_CONSTANT is subject to CSE and legalization, transforms could potentially obscure the value (and create extra work for the selector). The register bank of a G_CONSTANT is also meaningful, so this could throw off future folding and legalization logic for AMDGPU. This will be much more convenient to work with than needing to call getConstantVRegVal and checking if it may have failed for every constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth immarg operands, many of which need inspection during lowering. Having to find the value in a register is going to add a lot of boilerplate and waste compile time. SelectionDAG has always provided TargetConstant for constants which should not be legalized or materialized in a register. The distinction between Constant and TargetConstant was somewhat fuzzy, and there was no automatic way to force usage of TargetConstant for certain intrinsic parameters. They were both ultimately ConstantSDNode, and it was inconsistently used. It was quite easy to mis-select an instruction requiring an immediate. For SelectionDAG, start emitting TargetConstant for these arguments, and using timm to match them. Most of the work here is to cleanup target handling of constants. Some targets process intrinsics through intermediate custom nodes, which need to preserve TargetConstant usage to match the intrinsic expectation. Pattern inputs now need to distinguish whether a constant is merely compatible with an operand or whether it is mandatory. The GlobalISelEmitter needs to treat timm as a special case of a leaf node, simlar to MachineBasicBlock operands. This should also enable handling of patterns for some G_* instructions with immediates, like G_FENCE or G_EXTRACT. This does include a workaround for a crash in GlobalISelEmitter when ARM tries to uses "imm" in an output with a "timm" pattern source. llvm-svn: 372285
* gn build: Merge r372282GN Sync Bot2019-09-191-0/+1
| | | | llvm-svn: 372283
* [utils] Add minimal support for MIR inputs to update_llc_test_checks.pyRoman Tereshin2019-09-181-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | update_{llc,mir}_test_checks.py applicability is determined by the output (assembly or MIR), not the input, which makes update_llc_test_checks.py the right tool to generate tests that start at MIR and stop at the final assembly. This commit adds the minimal support for this path. Main limitation that remains: - MIR has to have LLVM IR section, and the CHECK lines will be inserted into the LLVM IR functions that correspond to the MIR functions. Running ../utils/update_llc_test_checks.py --llc-binary ./bin/llc on a slightly modified ../test/CodeGen/X86/bad-tls-fold.mir produces the following diff: +# NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py +# RUN: llc %s -o - | FileCheck %s --- | target triple = "x86_64-unknown-linux-gnu" @@ -6,17 +7,31 @@ @i = external thread_local global i32 define i32 @or() { + ; CHECK-LABEL: or: + ; CHECK: # %bb.0: # %entry + ; CHECK-NEXT: movq {{.*}}(%rip), %rax + ; CHECK-NEXT: orq $7, %rax + ; CHECK-NEXT: movq i@{{.*}}(%rip), %rcx + ; CHECK-NEXT: orq %rax, %rcx + ; CHECK-NEXT: movl %fs:(%rcx), %eax + ; CHECK-NEXT: retq entry: ret i32 undef } - define i32 @and() { + ; CHECK-LABEL: and: + ; CHECK: # %bb.0: # %entry + ; CHECK-NEXT: movq {{.*}}(%rip), %rax + ; CHECK-NEXT: orq $7, %rax + ; CHECK-NEXT: movq i@{{.*}}(%rip), %rcx + ; CHECK-NEXT: andq %rax, %rcx + ; CHECK-NEXT: movl %fs:(%rcx), %eax + ; CHECK-NEXT: retq entry: ret i32 undef } ... (not applied) llvm-svn: 372277
* [utils] Amend update_llc_test_checks.py to non-llc tooling, NFCRoman Tereshin2019-09-181-3/+4
| | | | | | | | Very minor change aiming to make it easier to extend the script downstream to support non-llc, but llc-like tools. The main objective is to decrease the probability of merge conflicts. llvm-svn: 372276
* gn build: Merge r372267GN Sync Bot2019-09-181-0/+1
| | | | llvm-svn: 372268
* gn build: Merge r372264GN Sync Bot2019-09-181-0/+1
| | | | llvm-svn: 372265
* Fix compile-time regression caused by rL371928Daniel Sanders2019-09-181-30/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Also fixup rL371928 for cases that occur on our out-of-tree backend There were still quite a few intermediate APInts and this caused the compile time of MCCodeEmitter for our target to jump from 16s up to ~5m40s. This patch, brings it back down to ~17s by eliminating pretty much all of them using two new APInt functions (extractBitsAsZExtValue(), insertBits() but with a uint64_t). The exact conditions for eliminating them is that the field extracted/inserted must be <=64-bit which is almost always true. Note: The two new APInt API's assume that APInt::WordSize is at least 64-bit because that means they touch at most 2 APInt words. They statically assert that's true. It seems very unlikely that someone is patching it to be smaller so this should be fine. Reviewers: jmolloy Reviewed By: jmolloy Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67686 llvm-svn: 372243
* gn build: Merge r372238GN Sync Bot2019-09-181-0/+2
| | | | llvm-svn: 372239
* gn build: Merge r372168GN Sync Bot2019-09-171-2/+0
| | | | llvm-svn: 372173
* gn build: Merge r372162GN Sync Bot2019-09-171-0/+2
| | | | llvm-svn: 372163
OpenPOWER on IntegriCloud