Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-02-12T13:06:29+00:00 2020-02-12T13:06:29+00:00 Jeremy Morse jeremy.morse@sony.com 2020-02-05T17:27:44+00:00 urn:sha1:4eb45a05a78f7c80bbec0453bc225deebec06209 This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref. (cherry picked from commit 6531a78ac4b5b229bce272706593a0bc873877d7) 2020-01-07T15:10:25+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2019-12-09T11:37:14+00:00 urn:sha1:f26ed6e47cb8b080c236d11c4942a12265180084 Don't overwrite existing target-cpu attributes. I've often found the replacement behavior annoying, and this is inconsistent with how the fast math command line flags interact with the function attributes. Does not yet change target-features, since I think that should behave as a concatenation. 2019-12-25T00:27:51+00:00 Fangrui Song maskray@google.com 2019-12-25T00:11:33+00:00 urn:sha1:a36ddf0aa9db5c1086e04f56b5f077b761712eb5 2019-12-25T00:05:15+00:00 Fangrui Song maskray@google.com 2019-12-25T00:02:47+00:00 urn:sha1:eb16435b5e5df68d2410bbe4c08ef8ce8aa8b2f4 2019-12-24T23:57:33+00:00 Fangrui Song maskray@google.com 2019-12-24T23:52:21+00:00 urn:sha1:502a77f125f43ffde57af34d3fd1b900248a91cd 2019-12-20T14:03:34+00:00 Tom Weaver Tom.Weaver@Sony.com 2019-12-20T14:03:34+00:00 urn:sha1:453dc4d7ec5a3c3d8f54fc358bc5673834516d48 The calculator was considering instructions such as KILLs as clobbers of a physical address. This is wrong as meta instructions such as KILLs produce no output in the final program and thus don't clobber or change any physical location's value. As a result they're safe to ignore whilst calculating location list ranges. reviewers: aprantl, vsk diff revision: https://reviews.llvm.org/D70497 fixes: https://bugs.llvm.org/show_bug.cgi?id=38753 2019-12-09T12:52:10+00:00 Jeremy Morse jeremy.morse@sony.com 2019-12-09T11:26:44+00:00 urn:sha1:00e238896cd8ad3a7d715b8fb5f12a2e60af8a6f CodeGenPrepare::placeDebugValues moves variable location intrinsics to be immediately after the Value they refer to. This makes tracking of locations very easy; but it changes the order in which assignments appear to the debugger, from the source programs order to the order in which the optimised program computes values. This then leads to PR43986 and PR38754, where variable locations that were in a conditional block are made unconditional, which is highly misleading. This patch adjusts placeDbgValues to only re-order variable location intrinsics if they use a Value before it is defined, significantly reducing the damage that it does. This is still not 100% safe, but the rest of CodeGenPrepare needs polishing to correctly update debug info when optimisations are performed to fully fix this. This will probably break downstream debuginfo tests -- if the instruction-stream position of variable location changes isn't the focus of the test, an easy fix should be to manually apply placeDbgValues' behaviour to the failing tests, moving dbg.value intrinsics next to SSA variable definitions thus: %foo = inst1 %bar = ... %baz = ... void call @llvm.dbg.value(metadata i32 %foo, ... to %foo = inst1 void call @llvm.dbg.value(metadata i32 %foo, ... %bar = ... %baz = ... This should return your test to exercising whatever it was testing before. Differential Revision: https://reviews.llvm.org/D58453 2019-11-08T10:30:33+00:00 Hans Wennborg hans@chromium.org 2019-11-08T10:30:33+00:00 urn:sha1:ff3b513495c04d87799b3c5a98ddcdb6996af4f3 This triggered asserts in the Chromium build, see https://crbug.com/1022729 for details and reproducer. > Without this change, when a nested tag type of any kind (enum, class, > struct, union) is used as a variable type, it is emitted without > emitting the parent type. In CodeView, parent types point to their inner > types, and inner types do not point back to their parents. We already > walk over all of the parent scopes to build the fully qualified name. > This change simply requests their type indices as we go along to enusre > they are all emitted. > > Fixes PR43905 > > Reviewers: akhuang, amccarth > > Differential Revision: https://reviews.llvm.org/D69924 2019-11-07T21:58:01+00:00 Reid Kleckner rnk@google.com 2019-11-06T23:04:52+00:00 urn:sha1:d91ed80e97ac9bfcfb02440874ed8b9a51c9491e Without this change, when a nested tag type of any kind (enum, class, struct, union) is used as a variable type, it is emitted without emitting the parent type. In CodeView, parent types point to their inner types, and inner types do not point back to their parents. We already walk over all of the parent scopes to build the fully qualified name. This change simply requests their type indices as we go along to enusre they are all emitted. Fixes PR43905 Reviewers: akhuang, amccarth Differential Revision: https://reviews.llvm.org/D69924 2019-10-15T10:46:24+00:00 Jeremy Morse jeremy.morse.llvm@gmail.com 2019-10-15T10:46:24+00:00 urn:sha1:ed29dbaafa49bb8c9039a35f768244c394411fea This patch kills off a significant user of the "IsIndirect" field of DBG_VALUE machine insts. Brought up in in PR41675, IsIndirect is techncally redundant as it can be expressed by the DIExpression of a DBG_VALUE inst, and it isn't helpful to have two ways of expressing things. Rather than setting IsIndirect, have DBG_VALUE creators add an extra deref to the insts DIExpression. There should now be no appearences of IsIndirect=True from isel down to LiveDebugVariables / VirtRegRewriter, which is ensured by an assertion in LDVImpl::handleDebugValue. This means we also get to delete the IsIndirect handling in LiveDebugVariables. Tests can be upgraded by for example swapping the following IsIndirect=True DBG_VALUE: DBG_VALUE $somereg, 0, !123, !DIExpression(DW_OP_foo) With one where the indirection is in the DIExpression, by _appending_ a deref: DBG_VALUE $somereg, $noreg, !123, !DIExpression(DW_OP_foo, DW_OP_deref) Which both mean the same thing. Most of the test changes in this patch are updates of that form; also some changes in how the textual assembly printer handles these insts. Differential Revision: https://reviews.llvm.org/D68945 llvm-svn: 374877