summaryrefslogtreecommitdiffstats
path: root/llvm/utils
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* gn build: Merge r372149GN Sync Bot2019-09-171-0/+1
| | | | llvm-svn: 372150
* [TableGen] CodeGenMapTable - Don't dereference a dyn_cast result. NFCI.Simon Pilgrim2019-09-171-2/+2
| | | | | | The static analyzer is warning about potential null dereferences of dyn_cast<> results - in these cases we can safely use cast<> directly as we know that these cases should all be the correct type, which is why its working atm and anyway cast<> will assert if they aren't. llvm-svn: 372146
* gn build: (manually) merge r372076Nico Weber2019-09-172-1/+21
| | | | llvm-svn: 372123
* [SVE][MVT] Fixed-length vector MVT rangesGraham Hunter2019-09-171-2/+8
| | | | | | | | | | | | | | | | | * Reordered MVT simple types to group scalable vector types together. * New range functions in MachineValueType.h to only iterate over the fixed-length int/fp vector types. * Stopped backends which don't support scalable vector types from iterating over scalable types. Reviewers: sdesmalen, greened Reviewed By: greened Differential Revision: https://reviews.llvm.org/D66339 llvm-svn: 372099
* [git-llvm] Do not reinvent `@{upstream}` (take 2)David Zarzycki2019-09-171-9/+9
| | | | | | | | | | | | This makes git-llvm more of a thin wrapper around git while temporarily maintaining backwards compatibility with past git-llvm behavior. Using @{upstream} makes git-llvm more robust when used with a nontrivial local repository. https://reviews.llvm.org/D67389 llvm-svn: 372070
* Revert r372035: "[lit] Make internal diff work in pipelines"Joel E. Denny2019-09-165-276/+241
| | | | | | This breaks a Windows bot. llvm-svn: 372051
* Add libc to path mappings in git-llvm.David L. Jones2019-09-161-0/+1
| | | | llvm-svn: 372048
* [lit] Make internal diff work in pipelinesJoel E. Denny2019-09-165-241/+276
| | | | | | | | | | | | | | | | | | | | | | | | | | | When using lit's internal shell, RUN lines like the following accidentally execute an external `diff` instead of lit's internal `diff`: ``` # RUN: program | diff file - # RUN: not diff file1 file2 | FileCheck %s ``` Such cases exist now, in `clang/test/Analysis` for example. We are preparing patches to ensure lit's internal `diff` is called in such cases, which will then fail because lit's internal `diff` cannot currently be used in pipelines and doesn't recognize `-` as a command-line option. To enable pipelines, this patch moves lit's `diff` implementation into an out-of-process script, similar to lit's `cat` implementation. A follow-up patch will implement `-` to mean stdin. Reviewed By: probinson, stella.stamenova Differential Revision: https://reviews.llvm.org/D66574 llvm-svn: 372035
* gn build: Merge r371976Nico Weber2019-09-162-0/+2
| | | | llvm-svn: 371977
* gn build: Merge r371965Nico Weber2019-09-161-0/+1
| | | | llvm-svn: 371966
* gn build: Merge r371959Nico Weber2019-09-161-1/+0
| | | | llvm-svn: 371961
* [CodeEmitter] Support instruction widths > 64 bitsJames Molloy2019-09-151-37/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally). This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets). When Inst.BitWidth > 64 the prototype changes to: void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI, SmallVectorImpl<MCFixup> &Fixups, APInt &Inst, APInt &Scratch, const MCSubtargetInfo &STI); The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can. Similarly the operand encoding prototype changes to: getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI); That is, the operand is passed by reference as APInt rather than returned as uint64_t. To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets. llvm-svn: 371928
* gn build: pacify "gn format" after 371102Nico Weber2019-09-131-0/+2
| | | | llvm-svn: 371858
* gn build: (manually) merge r371834, take 2Nico Weber2019-09-133-41/+31
| | | | llvm-svn: 371851
* Revert "gn build: (manually) merge r371834"Nico Weber2019-09-132-21/+39
| | | | | | | | This reverts commit abc7e2b6004cd693cf3b6dedbc7908e099c7ac6a. The commit was incomplete. I'll revert and reland the full commit, so that the correct change is a single commit. llvm-svn: 371850
* gn build: (manually) merge r371834Nico Weber2019-09-132-39/+21
| | | | llvm-svn: 371849
* gn build: Merge r371822Nico Weber2019-09-131-0/+1
| | | | llvm-svn: 371848
* gn build: (manually) merge r371787Nico Weber2019-09-133-1/+19
| | | | llvm-svn: 371847
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-133-0/+41
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 371834
* test-release.sh: Don't use chrpath on SolarisRainer Orth2019-09-121-2/+5
| | | | | | | | | | | | When trying to run test-release.sh on Solaris 11.4 for 9.0.0 rc4, I failed initially because Solaris lacks chrpath. This patch accounts for that and allowed the run to continue. Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D67484 llvm-svn: 371741
OpenPOWER on IntegriCloud