vectorization
Hi, In my architecture I have simd instructions with several simd levels. I have load and store which operate on 8 half words. I have add and sub for 4 half words I have mul which operates on 2 half words. How can I utilize all of them? Is that enough just to describe each one of these instructions? What should be UNITS_PER_SIMD_WORD for this port? Thanks, Roy.
Re: Edit-and-continue
Ian, The idea is to create a program database of the compiled program on a full compile. Then when asked to re-compile with the edit-and-continue switch, it only looks for changed code and compiles those few lines. Everything else it needs to carry out compilation is there from previous full-compile as was originally parsed, or from subsequent edit-and-continue compiles which updated the database. The resulting changes are passed to gdb for insertion into the running program's memory in real-time. On Sun Jul 18th, 2010 2:45 AM EDT Ian Lance Taylor wrote: >Rick Hodgin writes: > >> To my knowledge, GCC does not currently support any edit-and-continue >> abilities. Is this still true? And if so, are there any plans to introduce >> it at some point? > >I don't see how it makes sense to add edit-and-continue to gcc. >Compilation times are too slow, but they aren't *that* slow. Are you >thinking about gdb? Or the linker? > >Ian
Re: Edit-and-continue
Rick Hodgin wrote: Ian, The idea is to create a program database of the compiled program on a full compile. Then when asked to re-compile with the edit-and-continue switch, it only looks for changed code and compiles those few lines. Everything else it needs to carry out compilation is there from previous full-compile as was originally parsed, or from subsequent edit-and-continue compiles which updated the database. Unlikely to be feasible in my view without slowing down compilation substantially. The resulting changes are passed to gdb for insertion into the running program's memory in real-time. On Sun Jul 18th, 2010 2:45 AM EDT Ian Lance Taylor wrote: Rick Hodgin writes: To my knowledge, GCC does not currently support any edit-and-continue abilities. Is this still true? And if so, are there any plans to introduce it at some point? I don't see how it makes sense to add edit-and-continue to gcc. Compilation times are too slow, but they aren't *that* slow. Are you thinking about gdb? Or the linker? Ian
Re: Edit-and-continue
On 18 July 2010 16:25, Rick Hodgin wrote: > Ian, > > The idea is to create a program database of the compiled program on a full > compile. Then when asked to re-compile with the edit-and-continue switch, it > only looks for changed code and compiles those few lines. Everything else it > needs to carry out compilation is there from previous full-compile as was > originally parsed, or from subsequent edit-and-continue compiles which > updated the database. > > The resulting changes are passed to gdb for insertion into the running > program's memory in real-time. That might be harder to do for optimised code, where there isn't necessarily a direct correspondence between individual source lines and executable code. IIUC Visual Studio will only debug unoptimised code, gcc doesn't have the same distinction between "debug build" and "release build" - you can debug optimised code. It would also need more integration between gcc and gdb than currently exists.
Re: Edit-and-continue
On 18/07/2010 16:28, Robert Dewar wrote: > Rick Hodgin wrote: >> Ian, >> >> The idea is to create a program database of the compiled program on a >> full compile. Then when asked to re-compile with the >> edit-and-continue switch, it only looks for changed code and compiles >> those few lines. Everything else it needs to carry out compilation is >> there from previous full-compile as was originally parsed, or from >> subsequent edit-and-continue compiles which updated the database. > > Unlikely to be feasible in my view without slowing down compilation > substantially. I think you're probably assuming too much. Tom T. is working on an incremental compiler, isn't he? I expect that that and LTO between them would / could give us all the tools we needed to make an EAC-friendly compiler. But yes, OP, it's a long-term project. cheers, DaveK
Re: Edit-and-continue
Rick Hodgin writes: > The idea is to create a program database of the compiled program on a > full compile. Then when asked to re-compile with the edit-and-continue > switch, it only looks for changed code and compiles those few > lines. Everything else it needs to carry out compilation is there from > previous full-compile as was originally parsed, or from subsequent > edit-and-continue compiles which updated the database. This idea is related to Tom Tromey's incremental compiler work (http://gcc.gnu.org/wiki/IncrementalCompiler) and to Per Bothner's compiler server work (http://per.bothner.com/papers/GccSummit03-slides/index.html). Neither project is currently active. I believe that Diego Novillo is currently doing some work along these lines but I don't know what the status is. Ian
Re: [Bulk] Re: Edit-and-continue
If you are willing to restrict edit-and-continue to whole procedures then minimal changes to the compiled code for procedure entry points is all that is required (well that and dlopen). Terrence MIller On 7/18/2010 12:14 PM, Dave Korn wrote: On 18/07/2010 16:28, Robert Dewar wrote: Rick Hodgin wrote: Ian, The idea is to create a program database of the compiled program on a full compile. Then when asked to re-compile with the edit-and-continue switch, it only looks for changed code and compiles those few lines. Everything else it needs to carry out compilation is there from previous full-compile as was originally parsed, or from subsequent edit-and-continue compiles which updated the database. Unlikely to be feasible in my view without slowing down compilation substantially. I think you're probably assuming too much. Tom T. is working on an incremental compiler, isn't he? I expect that that and LTO between them would / could give us all the tools we needed to make an EAC-friendly compiler. But yes, OP, it's a long-term project. cheers, DaveK
Re: [Bulk] Re: Edit-and-continue
Terrence, Procedure entry points, global and local variable locations in memory, structure definitions and offsets, etc. These would all have to be updated as changes are made, and that means each reference used in the executable would need to be updated, and that could mean several source files are recompiled with a single change which affects it. And if there are shared resources loaded, each of those would have to be updated as well, that is if we wanted to go "whole hog" like that. Otherwise, we could limit the changes to only the currently-executing program. The idea of having function entry points across the board for all executed code would be required, allowing those links to be updated dynamically at run-time. We could even use a memory-based lookup table that's updated by gdb to the new entry points for the executable code. It would be slower for execution, but for development the time savings would be there because changes could be made on the fly, recompiled, memory variables changed as needed, and then continue execution without restarting the entire app. The ability would also have to be created to allow local variable re-mapping across these updates, so that if the stack changed, the data on the stack is migrated from its old locations to the new ones. This would be a table built by gcc that's passed to gdb for each function, where gdb updates the stack in that way. If parent functions on the call stack were updated, they would have to be altered on the stack as well. This could be accommodated by automatically including a specified amount of "extra space" in local variable space per function entry point, something like 32 bytes (eight 4-byte variables) by default, with a compiler switch to increase that block size. This extra space would allow for a certain number of new variables before a full recompile is required again. We could also have #pragma-like statements for individual functions where we know some heavy changes will be used, to give them an extra 512 bytes, or whatever's specified. - Rick C. Hodgin On Sun, 2010-07-18 at 12:36 -0700, Terrence Miller wrote: > If you are willing to restrict edit-and-continue to whole procedures > then minimal changes to the compiled > code for procedure entry points is all that is required (well that and > dlopen). > >Terrence MIller > > On 7/18/2010 12:14 PM, Dave Korn wrote: > > On 18/07/2010 16:28, Robert Dewar wrote: > > > >> Rick Hodgin wrote: > >> > >>> Ian, > >>> > >>> The idea is to create a program database of the compiled program on a > >>> full compile. Then when asked to re-compile with the > >>> edit-and-continue switch, it only looks for changed code and compiles > >>> those few lines. Everything else it needs to carry out compilation is > >>> there from previous full-compile as was originally parsed, or from > >>> subsequent edit-and-continue compiles which updated the database. > >>> > >> Unlikely to be feasible in my view without slowing down compilation > >> substantially. > >> > >I think you're probably assuming too much. Tom T. is working on an > > incremental compiler, isn't he? I expect that that and LTO between them > > would > > / could give us all the tools we needed to make an EAC-friendly compiler. > > > >But yes, OP, it's a long-term project. > > > > cheers, > >DaveK > > > > > > > >
Re: Edit-and-continue
On Sun, 2010-07-18 at 19:46 +0100, Jonathan Wakely wrote: > On 18 July 2010 16:25, Rick Hodgin wrote: > > Ian, > > > > The idea is to create a program database of the compiled program on a full > > compile. Then when asked to re-compile with the edit-and-continue switch, > > it only looks for changed code and compiles those few lines. Everything > > else it needs to carry out compilation is there from previous full-compile > > as was originally parsed, or from subsequent edit-and-continue compiles > > which updated the database. > > > > The resulting changes are passed to gdb for insertion into the running > > program's memory in real-time. > > That might be harder to do for optimised code, where there isn't > necessarily a direct correspondence between individual source lines > and executable code. IIUC Visual Studio will only debug unoptimised > code, gcc doesn't have the same distinction between "debug build" and > "release build" - you can debug optimised code. It would also need > more integration between gcc and gdb than currently exists. Jonathan, Visual Studio will debug optimized code, but it is difficult to do because of the loss of 1:1 ratio between source code and executable instructions. This is especially difficult in mixed-mode where you see source code alongside disassembled machine code (assembly instructions). Plus, the VS optimizations move loop tests to unusual locations for the target CPU, etc. But edit-and-continue is always available in Visual Studio if the original program database was specified when last compiled. The integration would have to be added, but if we can produce through gcc (and ultimately g++) a fixed kind of output that describes "what's changed" since it was re-compiled, then it would be easy to add those features to gdb, because the only ones required would be: 1) Update to a memory table for function offsets 2) Update to global memory space to move old variables to new locations 3) Update to local memory space to move old variables to new locations 4) Ability to add new global, local memory variables. 5) Ability to add new functions to the table. Everything else should just be loading the newly changed functions to some location in memory that gdb will likely assign, so as to derive its location for the memory-based table, and to leave everything that did not change where it was. To be clear: I'm talking about creating this ability to generate function call code that does not directly call its target function offset, but instead calls a known location in memory that is rigid and unchanging always, which itself references either dynamically updated code as needed, or calls a reference into a memory-based table which points to the new function locations. Just my thoughts. - Rick C. Hodgin
Re: onlinedocs/libstdc++ appears stale
On Thu, 15 Jul 2010, Jonathan Wakely wrote: >> How shall we address this for real? Is it really worthwhile to >> manually generate those .html.gz files for onlinedocs/libstdc++ or >> could we simply omit that step? Not sure it's really worth the >> hassles? > I have no idea why we gzip them, it certainly isn't saving any > diskspace if we end up with the .html *and* the .html.gz! The fact that we have both is a "bug" from all I can tell, not by design. > Benjamin has already started making some changes so that all the > libstdc++ docs can be generated automatically and put under > /onlinedocs as is done for the compiler docs. Ah, cool. Benjamin, if there is any way I can help, let me know! Gerald
Re: [Bulk] Re: Edit-and-continue
On 18 July 2010 20:52, Rick C. Hodgin wrote: > > The idea of having function entry points across the board for all > executed code would be required, allowing those links to be updated > dynamically at run-time. We could even use a memory-based lookup table > that's updated by gdb to the new entry points for the executable code. > It would be slower for execution, but for development the time savings > would be there because changes could be made on the fly, recompiled, > memory variables changed as needed, and then continue execution without > restarting the entire app. I run the compiler a lot more than I run the debugger, so I'm not entirely sold on the idea of development time savings, but I haven't used Edit-and-Continue so I can't say how useful it is.
Re: [Bulk] Re: Edit-and-continue
Jonathan, If you run Linux, you can download VMware, and install a version of Windows XP or later) and download Visual Studio Express from Microsoft for free. You can experiment with it and see how useful it is. It's pretty darned amazing actually. Once you use it, you'll always miss it. Simple little mistakes like: for (i=0; i On 18 July 2010 20:52, Rick C. Hodgin wrote: > > > > The idea of having function entry points across the board for all > > executed code would be required, allowing those links to be updated > > dynamically at run-time. We could even use a memory-based lookup table > > that's updated by gdb to the new entry points for the executable code. > > It would be slower for execution, but for development the time savings > > would be there because changes could be made on the fly, recompiled, > > memory variables changed as needed, and then continue execution without > > restarting the entire app. > > I run the compiler a lot more than I run the debugger, so I'm not > entirely sold on the idea of development time savings, but I haven't > used Edit-and-Continue so I can't say how useful it is.
Re: [Bulk] Re: Edit-and-continue
On 18 July 2010 23:15, Rick C. Hodgin wrote: > Jonathan, > > If you run Linux, you can download VMware, and install a version of > Windows XP or later) I don't have a licence to do that. > and download Visual Studio Express from Microsoft > for free. You can experiment with it and see how useful it is. It's > pretty darned amazing actually. Once you use it, you'll always miss it. > Simple little mistakes like: > > for (i=0; i > which should've been: > for (i=0; i<(some_var-1); ++i) > > can be changed on the fly. Those simple, tiny little mistakes that are > prevalent, save so much time by going "OH MAN!" smacking your forehead, > changing it quickly, and pressing the key combo to apply changes. > > It all takes 3 seconds, and you're continuing at the point in your > program where you were. Maybe we work on different kinds of program, but if I find the bug I'm looking for I don't usually stay in the debugger. The usefulness of this feature isn't really relevant on this list though, if it's useful to others then it doesn't matter much if I want to use it.
gcc-4.3-20100718 is now available
Snapshot gcc-4.3-20100718 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100718/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 162287 You'll find: gcc-4.3-20100718.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100718.tar.bz2 C front end and core compiler gcc-ada-4.3-20100718.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100718.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100718.tar.bz2 C++ front end and runtime gcc-java-4.3-20100718.tar.bz2 Java front end and runtime gcc-objc-4.3-20100718.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100718.tar.bz2The GCC testsuite Diffs from 4.3-20100711 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
suggest assert wide_int larger than hashval_t
I get this in 4.3.5:
../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
./include/hashtab.h:typedef unsigned int hashval_t;
unsigned HOST_WIDE_INT hwi;
hashval_t h, *hp;
...
const int shift = sizeof (hashval_t) * CHAR_BIT;
const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
int i;
h ^= (hashval_t) hwi;
for (i = 1; i < n; ++i)
{
hwi >>= shift; here
It looks about the same in 4.5.0 except without const:
int shift = (sizeof (hashval_t) * CHAR_BIT);
Something is amiss here locally, for the types to be the same size.
But maybe add gcc_assert(sizeof(hashval_t) < sizeof(HOST_WIDE_INT),
outside the loop? It should be optimized away anyway.
Maybe I'd get -Werror but I use -disable-bootstrap.
Native compiler is gcc, but old.
Thanks,
- Jay
