Re: Dimitar Dimitrov as TI PRU maintainer
On петък, 26 март 2021 г. 18:29:23 EET Jeff Law wrote: > I am pleased to announce that the GCC Steering Committee has appointed > Dimitar Dimitrov as maintainer of the TI PRU port in GCC. > > > Dimitar, please update your listing in the MAINTAINERS file. Sorry it's > taken so long to make this happen. It just kept slipping off my radar. > > > Thanks, > > Jeff Thank you for the honour. I have pushed the following as c314741a539244a947b94ac045611746c0f072e0 ChangeLog: * MAINTAINERS: Add myself as pru port maintainer. --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1722f0aa8fc..0fbbc0519d0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -96,6 +96,7 @@ nvptx portTom de Vries or1k port Stafford Horne pdp11 port Paul Koning powerpcspe portAndrew Jenner +pru port Dimitar Dimitrov riscv port Kito Cheng riscv port Palmer Dabbelt riscv port Andrew Waterman @@ -372,7 +373,6 @@ Bud Davis Chris Demetriou Sameera Deshpande Wilco Dijkstra -Dimitar Dimitrov Benoit Dupont de Dinechin Jason Eckhardt Bernd Edlinger
Copyright assignment
Hello, I would like to contribute GCC and Binutils ports for PRU [1]. I think "assigment for all future changes" is suitable for me. Can I get the copyright assignment forms? Regards, Dimitar [1] https://github.com/dinuxbg/gnupru
HW subregs in machine description
Hello, I'm a newbie working on a GCC port [1] for PRU [2]. In order to achieve ABI compatibility with the proprietary TI toolchain, I need my Machine Description to support HW register subfields as indipendent first-class registers. I could not find a relevant example in the GCC source. Looks like other ports declare subregisters to be the same entities as the corresponding main register (e.g. %al , %ah and %ax are treated by the GCC register allocator as one and same i386 register). So is it possible to describe subregs (independent fields) of 32-bit HW registers in GCC? Currently I'm attempting to describe the 8-bit PRU subregisters as the "real" target register set, and then work on defining 16-bit and 32-bit ALU operations. But I'm not sure if that would be efficient for a 32-bit PRU target, or feasible at all. To give an example, each 32-bit PRU register can hold either: - one 32-bit value (e.g. r10) - four independent 8-bit values (e.g. r10.b0, r10.b1, r10.b2, r10.b3). - two independent 16-bit values (e.g. r10.w0, r10.w2). - a mixture of the above (e.g. r10.w0, r10.b2, r10.b3). And here is an example of zero-extending one 8-bit and one 16-bit value, performing a 32-bit addition, and storing the result into another 8-bit subregister: add r10.b3, r10.b2, r10.w0 Thanks, Dimitar [1] https://github.com/dinuxbg/gnupru/tree/master/patches/gcc [2] http://elinux.org/images/d/da/Am335xPruReferenceGuide.pdf , section 5.3.2.5.2 "Registers"
Re: New feature: -fdump-gimple-nodes (once more, with feeling)
On Tue, Feb 13, 2024 at 01:46:11PM -0600, Robert Dubner wrote: ... > An example of a complete dump is available at > https://www.dubner.com/main.nodes.html. The C source code that generated > it is available at the end of > https://cobolworx.com/pages/dump-gimple-nodes.html > Hyperlinked text is useful. But I would love a graphical visualization even more, e.g. via either Graphviz or Plantuml. Regards, Dimitar
Re: How to target a processor with very primitive addressing modes?
On Thu, Jun 06, 2024 at 08:28:57PM +0200, Mikael Pettersson via Gcc wrote: > I'm working on a GCC backend for an older processor with very > primitive addressing support. The only way to load from or store to > memory is to compute the address into a register, and then use that > register in the load or store instruction. There are no immediate or > register offsets in memory accesses. > > So what I need is for GCC to transform any > > y = *(r + x); > > into > > t = r + x; > y = *t; > > and similarly for stores. The problem is that however I try to model > that (rewrites in define_expands, patterns in the define_insns, or > extra predicates and constraint letters) GCC goes into reload loops. I > suspect that reloading assumes it can use SP+offset addressing modes > without needing new temps. > > My current workaround is to reserve a register as a hidden spill temp, > and invoke code from the insn patterns to change the output templates > to the equivalent of the above when needed, but it's not a good > solution. > > Are there any targets in current GCC with similar constraints? > > Do you have any other recommendations on how to deal with these > constraints in GCC? > > Thanks in advance, > > /Mikael > > (p.s. please CC me on any replies as I'm not subscribed to this mailing list) Hi Mikael, Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From a quick search I see that the iq2000 and rx backends are rewriting some PLUS expression addresses with insn sequence to calculate the address. Regards, Dimitar
Re: git help: fortran_unsigned branch
On Fri, Aug 09, 2024 at 08:00:42PM +0200, Thomas Koenig via Gcc wrote: > Hi, > > I have managed to bring the fortran-unsigned branch into a state where > it can no longer be rebased. When I do a > > $ git rebase master It's unknown what is the state of your local master branch. So I would advise to rebase against master branch on the server: $ git fetch origin $ git rebase origin/master With the above I get the following result, which looks reasonably ok to me: $ git log --oneline --decorate 7bc60bc184f (HEAD) Add merge_bits. ae4b29f34c9 Min, MAX and ishft(c). e7a3c1f7841 Add test case for B, Z and O descriptors. 61b3f21a44b Add some rudimentary documentation. 4589ae45088 Implement dshift[lr], ibclr, ibset and ibits. d1cf578cb2a Add bit_size, btest and bgt plus friends. b285c13323b Bit functions, HUGE and DIGITS. c39c316ae8b Added BOZ support to UINT. 95927079ebc Added UINT intrinsic. 70a309048fe Iplement conversions from unsigned to different data types. c1e596f32f8 Add decimal formatted I/O for unsigneds. 65c571ffe65 A few fixes, add unsigned truncation warning. b84ec7f0242 Implement decimal list-directed I/O. f63906c5ff0 Add compile-time version of selected_unsigned_kind. c8e2ea0c39d Got some basic arithmetic working, test case now run-time. dd626ce9863 Very first program compiles. 1f93f691ff2 Initial version - add do-nothing -funsigned option and BT_UNSIGNED. d0bc1cbf6a8 (origin/trunk, origin/master, origin/HEAD) btf: Protect BTF_KIND_INFO against invalid kind > > I get > ... > > warning: skipped previously applied commit a6399bb27b3 > hint: use --reapply-cherry-picks to include skipped commits > hint: Disable this message with "git config advice.skippedCherryPicks false" Your origin/devel/fortran_unsigned has manually cherry-picked patches, which meanwhile got merged in "origin/master". I suspect those cherry-picked patches got sneaked in when a stale base was used for a git rebase (i.e. your local master branch). Warnings seem benign to me, but I would use the "gitk" tool to check the rebased branch. Just in case. > Successfully rebased and updated refs/heads/fortran_unsigned. > > and > > $ git status > On branch fortran_unsigned > Your branch and 'origin/devel/fortran_unsigned' have diverged, > and have 688 and 198 different commits each, respectively. > (use "git pull" to merge the remote branch into yours) > > nothing to commit, working tree clean > > and when I do "git pull" I get a lot of conflicts, basically having > to redo each commit by hand, as a conflict. If your local branch is tracking origin/devel/fortran_unsigned, then you are attempting to merge pre-rebase history with post-rebase history. In such case conflicts are expected. Don't pull the remote devel branch. To visualise the histories of your local and the remote branch: $ gitk -n1 HEAD origin/devel/fortran_unsigned Regards, Dimitar > > I have no idea what happened, or why, and despite the help of some > nice people on #gcc I have not made any progress on how to resolve it. > > Does anybody have any idea how to fix this? > > If not, I will just have to abandon the devel branch and work locally. > Not that I want to, but I guess it's better than not doing anything... > > Best regards > > Thomas
Re: git help: fortran_unsigned branch
On Fri, Aug 09, 2024 at 08:43:38PM +0200, Thomas Koenig wrote: > Hi Dimitar, > > > On Fri, Aug 09, 2024 at 08:00:42PM +0200, Thomas Koenig via Gcc wrote: > > > Hi, > > > > > > I have managed to bring the fortran-unsigned branch into a state where > > > it can no longer be rebased. When I do a > > > > > > $ git rebase master > > It's unknown what is the state of your local master branch. So I would > > advise to rebase against master branch on the server: > > > > $ git fetch origin > > $ git rebase origin/master > > OK, I did that. > > > With the above I get the following result, which looks reasonably ok to > > me: > > > > $ git log --oneline --decorate > > 7bc60bc184f (HEAD) Add merge_bits. > > ae4b29f34c9 Min, MAX and ishft(c). > > e7a3c1f7841 Add test case for B, Z and O descriptors. > > 61b3f21a44b Add some rudimentary documentation. > > 4589ae45088 Implement dshift[lr], ibclr, ibset and ibits. > > d1cf578cb2a Add bit_size, btest and bgt plus friends. > > b285c13323b Bit functions, HUGE and DIGITS. > > c39c316ae8b Added BOZ support to UINT. > > 95927079ebc Added UINT intrinsic. > > 70a309048fe Iplement conversions from unsigned to different data types. > > c1e596f32f8 Add decimal formatted I/O for unsigneds. > > 65c571ffe65 A few fixes, add unsigned truncation warning. > > b84ec7f0242 Implement decimal list-directed I/O. > > f63906c5ff0 Add compile-time version of selected_unsigned_kind. > > c8e2ea0c39d Got some basic arithmetic working, test case now run-time. > > dd626ce9863 Very first program compiles. > > 1f93f691ff2 Initial version - add do-nothing -funsigned option and > > BT_UNSIGNED. > > d0bc1cbf6a8 (origin/trunk, origin/master, origin/HEAD) btf: Protect > > BTF_KIND_INFO against invalid kind > > I get the same. > > > > > > > > > I get > > > ... > > > > > > warning: skipped previously applied commit a6399bb27b3 > > > hint: use --reapply-cherry-picks to include skipped commits > > > hint: Disable this message with "git config advice.skippedCherryPicks > > > false" > > > > Your origin/devel/fortran_unsigned has manually cherry-picked patches, > > which meanwhile got merged in "origin/master". I suspect those > > cherry-picked patches got sneaked in when a stale base was used for a > > git rebase (i.e. your local master branch). > > That actually sounds like a reasonable explanation of what could have > happened. Of course, it would have been nice to have known that > beforehand, or maybe even a warning from git... > > > Warnings seem benign to me, but I would use the "gitk" tool to check the > > rebased branch. Just in case. > > I've looked at it a bit and seen nothing untoward. > > > > > > Successfully rebased and updated refs/heads/fortran_unsigned. > > > > > > and > > > > > > $ git status > > > On branch fortran_unsigned > > > Your branch and 'origin/devel/fortran_unsigned' have diverged, > > > and have 688 and 198 different commits each, respectively. > > >(use "git pull" to merge the remote branch into yours) > > > > > > nothing to commit, working tree clean > > > > > > and when I do "git pull" I get a lot of conflicts, basically having > > > to redo each commit by hand, as a conflict. > > > > If your local branch is tracking origin/devel/fortran_unsigned, then you > > are attempting to merge pre-rebase history with post-rebase history. > > In such case conflicts are expected. Don't pull the remote devel > > branch. > > Hmm... but I already did. And, following other people's advice, > have reset the branch to upstream already (which may have been > another mistake). > > So, anything I can do about this, or have I messed up the > branch beyond repair? I assume you reset your local branch? The branch on the server does not seem to be affected. I suggest to rebase the remote branch using another local branch. Example: # Just in case, see which is your old local branch. $ git branch # Create a new local tracking branch $ git checkout -b fortran_unsigned-20240809 origin/devel/fortran_unsigned $ git rebase origin/master $ gitk -n1000 Once you have verified that local history looks good, you can upload it to the server. Notice that you override the history, which is a natural consequence of the rebase. $ git push --force origin HEAD:refs/heads/devel/fortran_unsigned Regards, Dimitar > > > > To visualise the histories of your local and the remote branch: > >$ gitk -n1 HEAD origin/devel/fortran_unsigned > > Looks like a nice tool. > > Best regards > > Thomas
Re: git help: fortran_unsigned branch
On Fri, Aug 09, 2024 at 09:40:08PM +0200, Thomas Koenig wrote: > Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov: > > > I assume you reset your local branch? The branch on the server does not > > seem to be affected. I suggest to rebase the remote branch using > > another local branch. Example: > > > ># Just in case, see which is your old local branch. > >$ git branch > > > ># Create a new local tracking branch > >$ git checkout -b fortran_unsigned-20240809 origin/devel/fortran_unsigned > >$ git rebase origin/master > >$ gitk -n1000 > > > > I tried that, with te same result: > > warning: skipped previously applied commit a6399bb27b3 > hint: use --reapply-cherry-picks to include skipped commits > hint: Disable this message with "git config advice.skippedCherryPicks false" > Successfully rebased and updated refs/heads/fortran_unsigned-20240809. > > $ git status > On branch fortran_unsigned-20240809 > Your branch and 'origin/devel/fortran_unsigned' have diverged, > and have 690 and 198 different commits each, respectively. > (use "git pull" to merge the remote branch into yours) You are redoing the rebase again. So it is expected to get the same warnings. > > So, it seems I already pushed something dubious previously. Yes, that seems to be the case. > > Any other ideas? No, sorry. I thought that getting to a cleanly rebased tree would be sufficient. > > > > Once you have verified that local history looks good, you can upload it > > to the server. Notice that you override the history, which is a natural > > consequence of the rebase. > >$ git push --force origin HEAD:refs/heads/devel/fortran_unsigned > > Not so long ago, I pushed to that branch, which led to a looong time > for checking. It got there eventually, but I do not want to repeat > that (and with more than ~40 times the number of commits, too). Is "checking" referring to regression testing of the development branch? Regards, Dimitar > > Best regards > > Thomas >
