Re: Marking nodes as addressable
On Fri, Feb 8, 2013 at 2:40 AM, Matt Davis wrote: > I have a GIMPLE_CALL statement and I want to mark the left-hand-side > value as being addressable (mark_addressable()). I am trying to force > the result to be stored on the stack, and not in a register. I know > the return of a call on an 64bit x86 is passed back to the caller in > the rax register. I want the return value to be immediately moved > onto the stack from rax after the caller resumes execution. When I do > mark the LHS of the call as being addressable, the ssa-expansion > fails, as the updated node is not in the var_partition when > get_rtx_for_ssa_name() is called. How can I tease the return of a > caller to be stored on the stack, in a temporary variable, instead of > lying around in a register, or being passed to other free registers? It depends on where you are doing that transform. If during GIMPLE optimization then the only good way is to use a new volatile local decl. You can create that with create_tmp_var_raw () and set TREE_THIS_VOLATILE on it. Richard. > -Matt
Re: Marking nodes as addressable
On Fri, Feb 8, 2013 at 7:20 PM, Richard Biener wrote: > On Fri, Feb 8, 2013 at 2:40 AM, Matt Davis wrote: >> I have a GIMPLE_CALL statement and I want to mark the left-hand-side >> value as being addressable (mark_addressable()). I am trying to force >> the result to be stored on the stack, and not in a register. I know >> the return of a call on an 64bit x86 is passed back to the caller in >> the rax register. I want the return value to be immediately moved >> onto the stack from rax after the caller resumes execution. When I do >> mark the LHS of the call as being addressable, the ssa-expansion >> fails, as the updated node is not in the var_partition when >> get_rtx_for_ssa_name() is called. How can I tease the return of a >> caller to be stored on the stack, in a temporary variable, instead of >> lying around in a register, or being passed to other free registers? > > It depends on where you are doing that transform. If during GIMPLE > optimization then the only good way is to use a new volatile local decl. > You can create that with create_tmp_var_raw () and set > TREE_THIS_VOLATILE on it. > > Richard. > >> -Matt Thanks Richard! -Matt
Re: SPEC2000 comparison of LLVM-3.2 and coming GCC4.8 on x86/x86-64
On Thu, Feb 07, 2013 at 11:46:04AM -0500, Vladimir Makarov wrote: > On 02/07/2013 11:09 AM, Richard Biener wrote: > >On Thu, Feb 7, 2013 at 4:26 PM, Vladimir Makarov wrote: > >>I've add pages comparing LLVM-3.2 and coming GCC 4.8 on > >>http://vmakarov.fedorapeople.org/spec/. > >> > >>The pages are accessible by links named GCC-LLVM comparison, 2013, x86 and > >>x86-64 SPEC2000 under link named 2013. You can find these links at the > >>bottom of the left frame. > >> > >>If you prefer email for reading the comparison, here is the copy of page > >>accessible by link named 2013: > >> > >> > >>Comparison of GCC and LLVM in 2013. > >> > >>This year the comparison is done on coming *GCC 4.8* and *LLVM 3.2* > >>which was released at the very end of 2012. > >> > >>As usually I am focused mostly on the compiler comparison as > >>*optimizing* compilers on major platform x86/x86-64. I don't consider > >>other aspects of the compilers as quality of debug information > >>(especially in optimizations modes), supported languages, standards > >>and extensions (e.g. OMP), supported targets and ABI, support of > >>just-in-time compilation etc. > >> > >>This year I did the comparison using following major options > >>equivalent with my point of view: > >> > >>o *-O0 -g, -Os, -O1, -O2, -O3, -O4* for LLVM3.2 > >>o *-O0 -g, -Os, -O1, -O2, -O3, -Ofast -flto* for GCC4.8 > >On the web-page you say that you use -Ofast -fno-fast-math (because > >that is what LLVM does with -O4). For GCC that's equivalent to -O3 > >(well, apart from that you enable -flto). So you can as well say you > >tested -O3 -flto. > I guess -Ofast -fno-fast-math is not just -O3 but you are right it > is pretty close. > >For 32bit you used -mtune=corei7 -march=i686 - did you disable > >CPU features like SSE on purpose? Vectorization at -O3+ should > >have used those (though without -ffast-math FP vectorization is > >seriously restricted). > Yes, I did it on purpose. Some 32-bit Linux distributions (e.g. > Fedora) uses this architecture. Another reason is that I'd like to > see how good compilers work with fp stack (I got an impression that > LLVM generates less fp stack regs shuffles, so I think we could > improve regstack.c). Although it is a dying architecture and > probably we should pay more attention to SSE architectures The FP stack is fortunately being put to rest in the museum of horrors. This said for processors starting from the Pentium and until SSE2 (the one with double precision) became available, the FXCH instruction was made essentially free from an execution unit and timing point of view (only taking a decoder slot). Stack shuffles implemented with the FXCH instruction were the only way to extract parallelism from floating point code. So as long as the stack shuffles are using FXCH, they are a valid optimization, and only hint at some historical burden that LLVM never has had to bear with. Regards, Gabriel
Copyright assignment
I'm interested in contributing to the gfortran compiler. Please send me any forms or instructions I need to follow regarding copyright assignment. Damian Rouson +1-510-600-2992 (mobile)
Re: gcc : c++11 : full support : eta?
On 01/24/2013 08:55 PM, Diego Novillo wrote: I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: "toolability" (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. I'm not quite sure that this clean split is possible, even after making amends for template instantiation. It's great for syntax-driven tools, but once you move beyond that, you tend to ignore stuff like destructors (or the cleanup attribute), life-times of temporaries etc., things which are just not visible in an AST. You have to reimplement many program analysis algorithms typically part of compiler optimizers, after lowering the AST to a less elaborate intermediate representation (a step which requires a fair amount of knowledge about the language in question). -- Florian Weimer / Red Hat Product Security Team
Re: gcc : c++11 : full support : eta?
On 02/08/2013 09:15 AM, Florian Weimer wrote: On 01/24/2013 08:55 PM, Diego Novillo wrote: I do see, however, a few areas where Clang/LLVM have gone that I do not think GCC is currently thinking of entering: "toolability" (for the lack of a better term). Clang's design follows a different path than g++. It's not just a code generating parser, it is a pure parser that also generates code. The difference makes it suitable for any kind of tool that needs to understand C++: static analyzers, code re-formatters, syntax highlighters, and other similar tools. Additionally, it is designed as a library, so it can be embedded into applications. I'm not quite sure that this clean split is possible, even after making amends for template instantiation. It's great for syntax-driven tools, but once you move beyond that, you tend to ignore stuff like destructors (or the cleanup attribute), life-times of temporaries etc., things which are just not visible in an AST. You have to reimplement many program analysis algorithms typically part of compiler optimizers, after lowering the AST to a less elaborate intermediate representation (a step which requires a fair amount of knowledge about the language in question). There's always going to be some things that are best done with the raw ASTs and others which are best done when we've got a lowered IL, CFG, SSA graph, etc. The big question is how well can you go from the output of clang into a lower level IR where you can do in depth analysis and how much you allow optimizers to perturb the results of the analysis. One could argue that clang -> gimple would be a useful translator to allow the nice things from the clang front-end, but also still allow the more in-depth analysis done by our tree-ssa code. Jeff
gcc-4.6-20130208 is now available
Snapshot gcc-4.6-20130208 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20130208/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 195903 You'll find: gcc-4.6-20130208.tar.bz2 Complete GCC MD5=0808c1bac86ad9f78d942a9901e01723 SHA1=bf811720c0f11d50329ac8d84e066f8fcaf4 Diffs from 4.6-20130201 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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: Copyright assignment
On Fri, Feb 8, 2013 at 4:00 AM, Damian Rouson wrote: > I'm interested in contributing to the gfortran compiler. Please send > me any forms or instructions I need to follow regarding copyright > assignment. http://www.fsf.org/volunteer They will send you some forms you need to fill out and return. Jeff
Re: Copyright assignment
On Fri, Feb 8, 2013 at 4:00 AM, Damian Rouson wrote: > I'm interested in contributing to the gfortran compiler. Please send > me any forms or instructions I need to follow regarding copyright > assignment. I sent the forms directly. - David
