Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.0 2020-02-25T14:19:52+00:00 2020-02-25T14:19:52+00:00 Hans Wennborg hans@chromium.org 2020-02-25T14:15:25+00:00 urn:sha1:2905a48c8790b530709305e984451ddab268c8e4 No functionality change (intended), but this seems to make the code a bit clearer for the compiler and maybe for human readers too. (cherry picked from commit edae4be8e21c5deb9a8ffc24a8c17e70b878bf39) 2020-01-12T01:28:22+00:00 Fangrui Song maskray@google.com 2020-01-12T00:27:25+00:00 urn:sha1:f719c540bb09cb5bfe37bc6283ea68e31949b3f4 In x86Disassembler{OneByte,TwoByte,...}Codes, "/* EmptyTable */" is very common. Omitting it saves lots of space. Also, there is no need to display a table entry in multiple lines. It is also common that the whole OpcodeDecision is { MODRM_ONEENTRY, 0}. Make use of zero-initialization. 2020-01-10T22:30:52+00:00 Vedant Kumar vsk@apple.com 2019-11-14T21:11:34+00:00 urn:sha1:a9052b4dfc1b25bd58480668d221365495fa9101 Add a predicate to MCInstDesc that allows tools to determine whether an instruction authenticates a pointer. This can be used by diagnostic tools to hint at pointer authentication failures. Differential Revision: https://reviews.llvm.org/D70329 rdar://55089604 2020-01-09T22:37:52+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2020-01-08T20:40:37+00:00 urn:sha1:10edb1d0d4a15812a71f8953bba96a4f1fc9d0af For arguments that are not expected to be materialized with G_CONSTANT, this was emitting predicates which could never match. It was first adding a meaningless LLT check, which would always fail due to the operand not being a register. Infer the cases where a literal should check for an immediate operand, instead of a register This avoids needing to invent a special way of representing timm literal values. Also handle immediate arguments in GIM_CheckLiteralInt. The comments stated it handled isImm() and isCImm(), but that wasn't really true. This unblocks work on the selection of all of the complicated AMDGPU intrinsics in future commits. 2020-01-09T22:37:52+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2020-01-08T17:53:15+00:00 urn:sha1:b4a647449fa01bd4e29bce5afef51770cddec664 The current implementation assumes there is an instruction associated with the transform, but this is not the case for timm/TargetConstant/immarg values. These transforms should directly operate on a specific MachineOperand in the source instruction. TableGen would assert if you attempted to define an equivalent GISDNodeXFormEquiv using timm when it failed to find the instruction matcher. Specially recognize SDNodeXForms on timm, and pass the operand index to the render function. Ideally this would be a separate render function type that looks like void renderFoo(MachineInstrBuilder, const MachineOperand&), but this proved to be somewhat mechanically painful. Add an optional operand index which will only be passed if the transform should only look at the one source operand. Theoretically it would also be possible to only ever pass the MachineOperand, and the existing renderers would check the parent. I think that would be somewhat ugly for the standard usage which may want to inspect other operands, and I also think MachineOperand should eventually not carry a pointer to the parent instruction. Use it in one sample pattern. This isn't a great example, since the transform exists to satisfy DAG type constraints. This could also be avoided by just changing the MachineInstr's arbitrary choice of operand type from i16 to i32. Other patterns have nontrivial uses, but this serves as the simplest example. One flaw this still has is if you try to use an SDNodeXForm defined for imm, but the source pattern uses timm, you still see the "Failed to lookup instruction" assert. However, there is now a way to avoid it. 2020-01-09T21:29:44+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2020-01-09T00:49:30+00:00 urn:sha1:f937b43fdb30b67facf616ad394976b08001ee89 Don't call computeAvailableFunctionFeatures for every instruction. 2020-01-09T19:55:03+00:00 Eric Astor epastor@google.com 2020-01-09T19:01:55+00:00 urn:sha1:1c545f6dbcbb3ada2dfef2c6afbc1ca8939135cb Summary: Extend D71677 to apply to all branch-target operands, rather than special-casing call instructions. Also add a regression test for llvm.org/PR44272, since this finishes fixing it. Reviewers: thakis, rnk Reviewed By: thakis Subscribers: merge_guards_bot, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72417 2020-01-09T15:32:57+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2020-01-08T15:53:22+00:00 urn:sha1:de08244d3da52215b8c63bc70d0a3c9e07b620a3 2020-01-09T15:29:31+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2020-01-08T23:57:44+00:00 urn:sha1:0274ed9dc75a0efb2b6130122226ee45f7e57dde 2020-01-08T00:02:31+00:00 Daniel Sanders daniel_l_sanders@apple.com 2020-01-08T00:02:06+00:00 urn:sha1:13922f3e9d0c8a0f2612c5e43c922099bbf74a79