[pull] master from llvm:master #73
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
The Hexagon itineraries are cunningly crafted such that functional units between
itineraries do not clash. Because all itineraries are bundled into the same DFA,
a functional unit index clash would cause an incorrect DFA to be generated.
A workaround for this is to ensure all itineraries declare the universe of all
possible functional units, but this isn't ideal for three reasons:
1) We only have a limited number of FUs we can encode in the packetizer, and
using the universe causes us to hit the limit without care.
2) Silent codegen faults are bad, and careful triage of the FU list shouldn't
be required.
3) Smooshing all itineraries into the same automaton allows combinations of
instruction classes that cannot exist, which bloats the table.
A simple solution is to allow "namespacing" packetizers.
Differential Revision: https://reviews.llvm.org/D66940
llvm-svn: 370508
Summary: This a follow up on: https://reviews.llvm.org/D62153 Handle the case where there are multiple object files that contain undefined references to the same function. We only generate a function variant if the existing symbol is directly called. See: emscripten-core/emscripten#8995 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67015 llvm-svn: 370509
gcc produces the error: error: specialization of ‘template<class T, class Enable> struct llvm::yaml::ScalarTraits’ in different namespace For all specializations outside of llvm::yaml. So I added llvm::yaml to these specializations to fix the errors on the bots building with gcc (/usr/bin/c++). llvm-svn: 370510
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Reviewers: arsenm, bogner Subscribers: jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, mgorny, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65919 llvm-svn: 370512
…onicalized to fadd. Remove the fsub test cases which were also testing fadd. Not sure how to prevent an fsub by constant getting turned into an fadd by negative constant. llvm-svn: 370515
llvm-svn: 370516
r370510 and r370504 Again only on gcc. llvm-svn: 370517
The sequence between the function call and the asm start may change without affecting what this test is looking for, but we should have a better idea about what that sequence looks like. llvm-svn: 370518
… r370510. llvm-svn: 370522
balazske
pushed a commit
to balazske/llvm-project
that referenced
this pull request
Nov 14, 2023
…vg (llvm#70914) This removes explicit invalidation of vg and svg that was done in `GDBRemoteRegisterContext::AArch64Reconfigure`. This was in fact covering up a bug elsehwere. Register information says that a write to vg also invalidates svg (it does not unless you are in streaming mode, but we decided to keep it simple and say it always does). This invalidation was not being applied until *after* AArch64Reconfigure was called. This meant that without those manual invalidates this happened: * vg is written * svg is not invalidated * Reconfigure uses the written vg value * Reconfigure uses the *old* svg value I have moved the AArch64Reconfigure call to after we've processed the invalidations caused by the register write, so we no longer need the manual invalidates in AArch64Reconfigure. In addition I have changed the order in which expedited registers as parsed. These registers come with a stop notification and include, amongst others, vg and svg. So now we: * Parse them and update register values (including vg and svg) * AArch64Reconfigure, which uses those values, and invalidates every register, because offsets may have changed. * Parse the expedited registers again, knowing that none of the values will have changed due to the scaling. This means we use the expedited registers during the reconfigure, but the invalidate does not mean we throw all of them away. The cost is we parse them twice client side, but this is cheap compared to a network packet, and is limited to AArch64 targets only. On a system with SVE and SME, these are the packets sent for a step: ``` (lldb) b-remote.async> < 803> read packet: $T05thread:p1f80.1f80;name:main.o;threads:1f80;thread-pcs:000000000040056c<...>a1:0800000000000000;d9:0400000000000000;reason:trace;#fc intern-state < 21> send packet: $xfffffffff200,200#5e intern-state < 516> read packet: $e4f2ffffffff000000<...>Ericsson#71 intern-state < 15> send packet: $Z0,400568,4#4d intern-state < 6> read packet: $OK#9a dbg.evt-handler < 16> send packet: $jThreadsInfo#c1 dbg.evt-handler < 224> read packet: $[{"name":"main.o","reason":"trace","registers":{"161":"0800000000000000",<...>}],"signal":5,"tid":8064}]]Ericsson#73 ``` You can see there are no extra register reads which means we're using the expedited registers. For a write to vg: ``` (lldb) register write vg 4 lldb < 37> send packet: $Pa1=0400000000000000;thread:1f80;#4a lldb < 6> read packet: $OK#9a lldb < 20> send packet: $pa1;thread:1f80;Ericsson#29 lldb < 20> read packet: $0400000000000000#04 lldb < 20> send packet: $pd9;thread:1f80;Ericsson#34 lldb < 20> read packet: $0400000000000000#04 ``` There is the initial P write, and lldb correctly assumes that SVG is invalidated by this also so we read back the new vg and svg values afterwards.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]. Want to support this open source service? Please star it : )