gcc-6-20171025 is now available
Snapshot gcc-6-20171025 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20171025/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 254090 You'll find: gcc-6-20171025.tar.xzComplete GCC SHA256=ae021981a29aee45ca7d307a9acb72dbe66ca644c492a7e84b0a3fe00fbdad14 SHA1=bbb26c13ec707938bef1c7027c81e5ae3fd19614 Diffs from 6-20171018 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-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: Global analysis of RTL
On Thu, Oct 19, 2017 at 8:46 AM, Geoff Wozniak wrote: > R0b0t1 writes: >> >> When I first looked at the GCC codebase, it seemed to me that most >> operations should be done on the GIMPLE representation as it contains the >> most information. Is there any reason you gravitated towards RTL? > > > Naiveté, really. > > My team and I didn’t know much about the code base when we started looking > at the problem, although we knew a little about the intermediate formats. > GIMPLE makes the analysis more complicated, although not impossible, and it > can make the cost model difficult to pin down. Raw assembly/machine code is > ideal, but then we have to deal with different platforms and would likely > have to do all the work in the linker. RTL is sufficiently low-level enough > (as far as we know) to start counting instructions, and platform independent > enough that we don’t have to parse machine code. > > Essentially, working with RTL makes the implementation a little easier but > we didn’t know that the pass infrastructure wasn’t in our favour. > > It’s likely we’ll turn our attention to GIMPLE and assembler/machine code, > unless we can come up with something (or anyone has a suggestion). > Admittedly I do not know much about compiler design, but your response has put some of what I read about analysis of RTL into context. It it is hard to be sure, but I think analysis of RTL has fallen out of favor and has been replaced with the analysis of intermediate languages. For example, compare clang and llvm's operation. The missing link is that you seem to be right about cost calculation. Cost calculation is difficult for high level operations. Would online analysis of the produced machine code be sufficient? That seems to be a popular solution from what I have read. Thanks for the response, and best of luck to you. Cheers, R0b0t1.
Re: Global analysis of RTL
Hi, On 26 October 2017 at 14:13, R0b0t1 wrote: > On Thu, Oct 19, 2017 at 8:46 AM, Geoff Wozniak wrote: >> R0b0t1 writes: >>> >>> When I first looked at the GCC codebase, it seemed to me that most >>> operations should be done on the GIMPLE representation as it contains the >>> most information. Is there any reason you gravitated towards RTL? >> >> >> Naiveté, really. >> >> My team and I didn’t know much about the code base when we started looking >> at the problem, although we knew a little about the intermediate formats. >> GIMPLE makes the analysis more complicated, although not impossible, and it >> can make the cost model difficult to pin down. Raw assembly/machine code is >> ideal, but then we have to deal with different platforms and would likely >> have to do all the work in the linker. RTL is sufficiently low-level enough >> (as far as we know) to start counting instructions, and platform independent >> enough that we don’t have to parse machine code. >> >> Essentially, working with RTL makes the implementation a little easier but >> we didn’t know that the pass infrastructure wasn’t in our favour. >> >> It’s likely we’ll turn our attention to GIMPLE and assembler/machine code, >> unless we can come up with something (or anyone has a suggestion). >> > > Admittedly I do not know much about compiler design, but your response > has put some of what I read about analysis of RTL into context. It it > is hard to be sure, but I think analysis of RTL has fallen out of > favor and has been replaced with the analysis of intermediate > languages. For example, compare clang and llvm's operation. It is not really being replaced (at least I am not aware of it). It is true that more and more of the high level optimisations are moved to gimple. When we move high level intermediate format to lower level intermediate format, we tend to lose some information and gets more closer to machine representation. An obvious example is, in RTL sign is not represented. Even in RTL, after reload, we will have one to one mapping fro RTL to actual machine instruction (i.e. more closer to asm). In short, gcc goes from generic to gimple to RTL as stamens are lowered from high level languages to asm. Thanks, Kugan > > The missing link is that you seem to be right about cost calculation. > Cost calculation is difficult for high level operations. Would online > analysis of the produced machine code be sufficient? That seems to be > a popular solution from what I have read. > > Thanks for the response, and best of luck to you. > > Cheers, > R0b0t1.
