cc0 -> CCmode questions
Segher Boessenkool schrieb: Btw, does GCC support clobbering registers in branches (or cbranch4 for that matter)? This requirement would come up when transitioning avr to cc_mode because cbranches would live post reload. Of course. You cannot have *reloads* on branches, that is all. Segher Does this also apply to input reloads? Suppose cbranch with constraints like "d,r" "n,r" for the operands to be compared, where d is a register class that can be compared against immediate, but registers in r can't be compared to n in general. For a case #2 target (only ccmode clobbers before reload), reload might generate an input reload for the constant in the cbranch. So this is for bidden? Johann
Re: cc0 -> CCmode questions
On 11/2/19 9:51 AM, Georg-Johann Lay wrote: > Segher Boessenkool schrieb: >>> Btw, does GCC support clobbering registers in branches (or >>> cbranch4 for that matter)? This requirement would come up when >>> transitioning avr to cc_mode because cbranches would live post reload. >> >> Of course. You cannot have *reloads* on branches, that is all. >> >> Segher > > Does this also apply to input reloads? > > Suppose cbranch with constraints like > > "d,r" > "n,r" > > for the operands to be compared, where d is a register class that > can be compared against immediate, but registers in r can't be > compared to n in general. > > For a case #2 target (only ccmode clobbers before reload), reload might > generate an input reload for the constant in the cbranch. > > So this is for bidden? This should work in the LRA world just fine. The problems are with output reloads, not input reloads. With an output reload on a branch you have to emit the reload at the target(s) of the branch as well as the fallthru path (if one exists). In theory we could do this for simple branches, but for indirects it'd be virtually impossible. jeff
Re: Fixing cvs2svn branchpoints
Joseph Myers : > And here are corresponding lists of tags where the commit cvs2svn > generated for the tag should be reparented. Make that issue 2, please. Also, open an issue 3 about how you want those mid-branch deletes handled. I agree that the right thing is just to nuke them, but I have a lot of plates in the air right now... Also please open reposurgeon issues about the svnmerge properties and the missing documentation. I might get to the svnmerge thing today, it should be a trivial tweak. The repository comparison is still grinding. It has turned up some content mismatches, fewer than last time, most in trunk/libgo. The reason for the "fewer" is that the Go version has learned how to correctly handle a corner case the Python did not - tag/branch delete followed by a recreation at a different root point. That's why this is commented out in the lift script: # Squash accidental trunk deletion and recreation. # Should no longer be needed due to branch recoloring. #<130803.1>,<138077>,<184996.1> squash I used to have to find defects like that by hand and patch them. Now there's a recoloring phase where branches and tags with multiple creations are handled by renaming all but the last such branch in each clique to a unique nonce name. This makes all the results from branch copies come out right, and none of the nonce names are ever visible in the final conversion. I'll go dive into the defect analysis now. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: cc0 -> CCmode questions
On Sat, Nov 02, 2019 at 10:14:15AM -0600, Jeff Law wrote: > On 11/2/19 9:51 AM, Georg-Johann Lay wrote: > > Segher Boessenkool schrieb: > >>> Btw, does GCC support clobbering registers in branches (or > >>> cbranch4 for that matter)? This requirement would come up when > >>> transitioning avr to cc_mode because cbranches would live post reload. > >> > >> Of course. You cannot have *reloads* on branches, that is all. Sigh. *Output reloads*, sorry for dropping a crucial word here :-/ > > Does this also apply to input reloads? > > This should work in the LRA world just fine. The problems are with > output reloads, not input reloads. In the old reload world as well. Only output reloads are a problem. > With an output reload on a branch you have to emit the reload at the > target(s) of the branch as well as the fallthru path (if one exists). Or you can do something *before* the branch, but that is different for every case, and harder to do anyway. If you insert the reloads at the jump target, you'll need to make a separate predecessor of the jump target and insert the reload *there*, if we aren't the only predecessor of that target. > In theory we could do this for simple branches, but for indirects it'd > be virtually impossible. Yup. Luckily most branches with outputs are not indirect branches. I would love if this problem was fixed once and for all (I only care about LRA here of course). Segher
gcc-9-20191102 is now available
Snapshot gcc-9-20191102 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20191102/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-9-branch revision 277745 You'll find: gcc-9-20191102.tar.xzComplete GCC SHA256=ccca50ed5b09b825f985b42f4ad6aae628cd4b7e511ae90180443409c70ab920 SHA1=2d721464a01f8a90a0141526d1b8f404a75fb2ab Diffs from 9-20191026 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
