Re: Moving to git
Jakub Jelinek writes: > On Mon, Aug 24, 2015 at 10:22:22AM +0200, Andreas Schwab wrote: >> Jakub Jelinek writes: >> >> > And for those really identifying them by sha1 hashes is significantly >> > worse than using monotonically increasing small number, sha1 hashes >> > are impossible to remember, and you don't know what is earlier and >> > what is later from just looking at it. >> >> git describe gives you such a number (relative to a tag). > > But it is not unique across different branches, It can't be, due to the distributed nature of git. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
fake/abnormal/eh edge question
I have a question about FAKE, EH, and ABNORMAL edges. I am not sure I understand all the implications of each type of edge from the description in cfg-flags.def. I am trying to implement dynamic stack alignment for MIPS and I have code that does the following: prologue copy incoming $sp to $12 (temp reg) align $sp copy $sp to $fp (after alignment so that $fp is also aligned) entry block copy $12 to virtual reg (DRAP) for accessing args and for restoring $sp exit block copy virtual reg (DRAP) back to $12 epilogue copy $12 to $sp to restore stack pointer This works fine as long as there as a path from the entry block to the exit block but in some cases (like gcc.dg/cleanup-8.c) we have a function that always calls abort (a non-returning function) and so there is no path from entry to exit and the exit block and epilogue get removed and the copy of $sp to $12 also gets removed because GCC sees no uses of $12. I want to preserve the copy of $sp to $12 and I also want to preserve the .cfi psuedo-ops (and code) in the exit block and epilogue in order for exception handling to work correctly. One way I thought of doing this is to create an edge from the entry block to the exit block but I am unsure of all the implications of creating a fake/eh/abnormal edge to do this and which I would want to use. Steve Ellcey sell...@imgctec.com
Re: fake/abnormal/eh edge question
On 08/25/2015 12:39 PM, Steve Ellcey wrote: I have a question about FAKE, EH, and ABNORMAL edges. I am not sure I understand all the implications of each type of edge from the description in cfg-flags.def. I am trying to implement dynamic stack alignment for MIPS and I have code that does the following: prologue copy incoming $sp to $12 (temp reg) align $sp copy $sp to $fp (after alignment so that $fp is also aligned) entry block copy $12 to virtual reg (DRAP) for accessing args and for restoring $sp exit block copy virtual reg (DRAP) back to $12 epilogue copy $12 to $sp to restore stack pointer This works fine as long as there as a path from the entry block to the exit block but in some cases (like gcc.dg/cleanup-8.c) we have a function that always calls abort (a non-returning function) and so there is no path from entry to exit and the exit block and epilogue get removed and the copy of $sp to $12 also gets removed because GCC sees no uses of $12. I want to preserve the copy of $sp to $12 and I also want to preserve the .cfi psuedo-ops (and code) in the exit block and epilogue in order for exception handling to work correctly. One way I thought of doing this is to create an edge from the entry block to the exit block but I am unsure of all the implications of creating a fake/eh/abnormal edge to do this and which I would want to use. Presumably it's the RTL DCE pass that's eliminating this stuff? Do you have the FRAME_RELATED bit set of those insns? But what I don't understand is why preserving the code is useful if it can't be reached. Maybe there's something about the dwarf2 unwinding that I simply don't understand -- I've managed to avoid learning about it for years. jeff
Re: GIMPLE-level if-converter with scratchpads --- Results from SPEC2006 FP analysis done at Richard`s request {late July / early August} --- results from running all the SPEC2006 CPU FP tests again a
Dear all, I have redone the SPEC2006 CPU FP tests again after adding "-march=native". Unfortunately, the results are not very good for the new if-converter. I believe this is the case because the CPU in question [details below] "only" has first-generation AVX, and, from what I`ve been told, at least AVX2 is needed for scatter/gather and/or masked loads/stores, and possibly even AVX512 [the 3rd generation]. As I have written before, in my opinion the new converter would be better than the old one if enough time and effort were to be spent on it, especially the time and effort to make it not add unneeded indirections. First, I will give the totals. Then, I`ll give the CPU details for better understanding what "-march=native" did [or at least should have done]. Then, I`ll give the per-subtest numbers that Richard requested. For concision, I will use "Richard`s check-in" to refer to the GCC I built from Richard`s check-in dated July 10 2015 with Git SHA "cb791e75379bc0c8b10bd13bcb24305c36fd504b" and "git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225652". [my reason for rebasing the relevant Git check-out to that point: quoting Richard`s check-in message: "PR tree-optimization/66823 * tree-if-conv.c (memrefs_read_or_written_unconditionally): Fix inverted predicate."] All the compilations were done with "-Ofast". The results, all integers, are the number of loops that were vectorized. Regards, Abe Richard`s check-in [i.e. *_old_* converter] no if-conversion-specific flags --- 8374 Richard`s check-in [i.e. *_old_* converter] "-ftree-loop-if-convert" but NOT "-ftree-loop-if-convert-stores" 8374 Richard`s check-in [i.e. *_old_* converter] both "-ftree-loop-if-convert" AND "-ftree-loop-if-convert-stores" - 8388 patched version of Richard`s check-in [i.e. *_new_* converter] no if-conversion-specific flags - 8275 patched version of Richard`s check-in [i.e. *_new_* converter] "-ftree-loop-if-convert" but NOT "-ftree-loop-if-convert-stores" 8275 patched version of Richard`s check-in [i.e. *_new_* converter] both "-ftree-loop-if-convert" AND "-ftree-loop-if-convert-stores" - 8275 CPU [from "/proc/cpuinfo"] -- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz stepping: 7 microcode : 0x710 cpu MHz : 2499.902 cache size : 15360 KB physical id : 0 siblings: 12 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 4999.80 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: [similarly for the cores numbered 1...23] kernel: 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Richard`s check-in [i.e. *_old_* converter] no if-conversion-specific flags --- 410.bwaves: 13 416.gamess: 3837 433.milc: 7 434.zeusmp: 138 435.gromacs: 172 436.cactusADM: 261 437.leslie3d: 92 444.namd: 0 450.soplex: 1 454.calculix: 436 459.GemsFDTD: 275 465.tonto: 943 470.lbm: 0 481.wrf: 2141 482.sphinx3: 58 998.specrand: 0 Richard`s check-in [i.e. *_old_* converter] "-ftree-loop-if-convert" but NOT "-ftree-loop-if-convert-stores" 410.bwaves: 13 416.gamess: 3837 433.milc: 7 434.zeusmp: 138 435.gromacs: 172 436.cactusADM: 261 437.leslie3d: 92 444.namd: 0 450.soplex: 1 454.calculix: 436 459.GemsFDTD: 275 465.tonto: 943 470.lbm: 0 481.wrf: 2141 482.sphinx3: 58 998.specrand: 0 Richard`s check-in [i.e. *_old_* converter] both "-ftree-loop-if-convert" AND "-ftree-loop-if-convert-stores" - 410.bwaves: 13 416.gamess: 3850 433.milc: 7 434.zeusmp: 138 435.gromacs: 173 436.cactusADM: 261 437.leslie3d: 92 444.namd: 0 450.soplex: 1 454.calculix: 436 459.GemsFDTD: 275 465.tonto: 943 470.lbm: 0 481.wrf: 2141 482.sphinx3: 58 998.specrand: 0 patched
Re: fake/abnormal/eh edge question
On Tue, 2015-08-25 at 14:44 -0600, Jeff Law wrote: > > I want to preserve the copy of $sp to $12 and I also want to preserve the > > .cfi psuedo-ops (and code) in the exit block and epilogue in order for > > exception handling to work correctly. One way I thought of doing this > > is to create an edge from the entry block to the exit block but I am > > unsure of all the implications of creating a fake/eh/abnormal edge to > > do this and which I would want to use. > Presumably it's the RTL DCE pass that's eliminating this stuff? Actually, it looks like is peephole2 that is eliminating the instructions (and .cfi psuedo-ops). > > Do you have the FRAME_RELATED bit set of those insns? > > But what I don't understand is why preserving the code is useful if it > can't be reached. Maybe there's something about the dwarf2 unwinding > that I simply don't understand -- I've managed to avoid learning about > it for years. I am not entirely sure I need the code or if I just need the .cfi psuedo-ops and that I need the code to generate the .cfi stuff. I wish I could avoid the dwarf unwinder but that seems to be the main problem I am having with stack realignment. Getting the cfi stuff right so that the unwinder works properly is proving very hard. Steve Ellcey sell...@imgtec.com
Re: fake/abnormal/eh edge question
On 08/25/2015 03:54 PM, Steve Ellcey wrote: On Tue, 2015-08-25 at 14:44 -0600, Jeff Law wrote: I want to preserve the copy of $sp to $12 and I also want to preserve the .cfi psuedo-ops (and code) in the exit block and epilogue in order for exception handling to work correctly. One way I thought of doing this is to create an edge from the entry block to the exit block but I am unsure of all the implications of creating a fake/eh/abnormal edge to do this and which I would want to use. Presumably it's the RTL DCE pass that's eliminating this stuff? Actually, it looks like is peephole2 that is eliminating the instructions (and .cfi psuedo-ops). Strange. I'm not sure why peep2 would be deleting those instructions, except perhaps as a side effect of a cfgcleanup or somesuch. that I simply don't understand -- I've managed to avoid learning about it for years. I am not entirely sure I need the code or if I just need the .cfi psuedo-ops and that I need the code to generate the .cfi stuff. I wish I could avoid the dwarf unwinder but that seems to be the main problem I am having with stack realignment. Getting the cfi stuff right so that the unwinder works properly is proving very hard. Yea, unfortunately I can't help much there. I see dwarf-anything and my eyes just glaze over and I thank the powers that be that Jakub, Jason and others are around to handle that stuff. jeff
gcc-5-20150825 is now available
Snapshot gcc-5-20150825 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150825/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 227197 You'll find: gcc-5-20150825.tar.bz2 Complete GCC MD5=b5248270b8c71ab824ac390f05da5db3 SHA1=16506414773f2f24032108340f83f68a896408a7 Diffs from 5-20150818 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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.
Re: Moving to git
On 08/24/2015 11:49 AM, Jeff Law wrote: On 08/24/2015 09:43 AM, Jakub Jelinek wrote: Not to mention we should keep the existing r123456 comments in bugzilla working, and I'm not convinced keeping a SVN version of the repository (frozen) for that purpose is the best idea. I'd like to keep the old ones working, but new references should probably be using the hash id and commit name. As for how to best keep the old r123456 links working, I don't know. Presumably those could be mapped behind the scenes to a git id. git-svn find-rev takes r123456 and returns a commit hash based on the git-svn-id in the git log; I don't see why we would need to break that moving forward, though I'm not sure how well it would work without reference to an actual SVN server. Jason
Re: Moving to git
Jason Merrill : > git-svn find-rev takes r123456 and returns a commit hash based on the > git-svn-id in the git log; I don't see why we would need to break that > moving forward, though I'm not sure how well it would work without reference > to an actual SVN server. It won't work at all, because git-svn won't. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Moving to git
On 08/24/2015 11:54 AM, Richard Earnshaw wrote: Why not use the output of 'git show -s --format=%ct-%h'? $ git show -s --format=%ct-%h master 1440153969-f57da59 That gives you a unix timestamp for the commit, followed by the hash. Now you've got a fully ordered way of referring to the commit, but still have access to the hash code. You don't even need to worry about the hash code, you can use the timestamp by itself. Given the timestamp, git log -1 --until 1440153969 will show you the relevant commit, or git rev-list HEAD --max-count=1 --until 1440153969 will give you the hash. So that seems like a suitable monotonically increasing identifier. What do you think, Jakub? Jason
Re: Moving to git
Jason Merrill writes: > So that seems like a suitable monotonically increasing identifier. Git does not guarantee it, though. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
