Re: RTL compression in GCC
On Mon, Aug 20, 2018 at 5:21 PM Martin Jambor wrote: > > Hello Alfonso, > > On Sat, Aug 18 2018, ALFONSO LUIS CASTANO MARIN wrote: > > Dear Martin, > > > > I am interested in contributing to GCC to speed-up the compiler and I > > thought that the issues related with RTL are very interesting. I wonder if > > still there has not been done any job in RTL compression and if you could > > point me to someone how could give me some hints about how to contribute in > > this. > > I suggest you discuss any GCC development ideas on the mailing list > gcc@gcc.gnu.org > > As far as RTL compression is concerned, I do not remember it being > discussed or proposed before. From what I can tell, we are not usually > looking at RTL memory footprint when dealing with excessive memory > consumption, one reason is likely that there is only one function in the > RTL representation at a time, as opposed to the whole compilation unit > in GIMPLE. Others will surely correct me if I am wrong, however, and > may even suggest other areas where compilation speed could be improved. There's the idea of threading the compiler. One major compile-time part of a -O0 compile for example is register allocation which happens at RTL time, so being able to register allocate multiple functions in parallel would be interesting eventually (with all the complex infrastructure requirements this brings up, like having multiple functions in RTL state at the same time). Richard. > Thanks, > > Martin
Re: RTL compression in GCC
Martin Jambor writes: > Hello Alfonso, > On Sat, Aug 18 2018, ALFONSO LUIS CASTANO MARIN wrote: >> Dear Martin, >> >> I am interested in contributing to GCC to speed-up the compiler and I >> thought that the issues related with RTL are very interesting. I wonder if >> still there has not been done any job in RTL compression and if you could >> point me to someone how could give me some hints about how to contribute in >> this. > > I suggest you discuss any GCC development ideas on the mailing list > gcc@gcc.gnu.org > > As far as RTL compression is concerned, I do not remember it being > discussed or proposed before. From what I can tell, we are not usually > looking at RTL memory footprint when dealing with excessive memory > consumption, one reason is likely that there is only one function in the > RTL representation at a time, as opposed to the whole compilation unit > in GIMPLE. Others will surely correct me if I am wrong, however, and > may even suggest other areas where compilation speed could be improved. FWIW, one RTL compression suggestion I remember being discussed way back when was the idea of storing only an instruction's INSN_CODE and operands and using them to reconstruct the whole RTL pattern on demand. That would have been fairly cheap to do in the old obstack-based days, but probably doesn't make as much sense now that RTL is garbage-collected. One area that seems a bit inefficient is that walking a block of insns and using their df info goes through: #define DF_INSN_INFO_GET(INSN) (df->insns[(INSN_UID (INSN))]) for every instruction. When profiling GCC in the past I've seen this be a significant source of cache misses. It might be more efficient to store the DF info in the instruction itself, in a similar way to block_symbol for SYMBOL_REF, but it's hard to say without trying it and measuring. I agree that other areas might be more important these days though. Thanks, Richard
Richard Sandiford appointed Global Reviewer
I am pleased to announce that the GCC Steering Committee has appointed Richard Sandiford as a Global Reviewer. Please join me in congratulating Richard on his new role. Richard, please update your listing in the MAINTAINERS file. Happy hacking! David
Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32
Bootstrap is done with msys2 on Windows 7. For the testsuite results see https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html signature.asc Description: OpenPGP digital signature
Questions/topics for UB BoF
Hello, For the upcoming Cauldron, I've registered a BoF on treatment of undefined behavior in GCC. To "promote" the BoF, collect some input prior to the event, and indirectly indicate my interests, I am offering the following light-hearted questionnaire. I would ask to mail responses directly to my address, not the list. If you prefer Google Forms, please fill https://goo.gl/forms/1sLhMtLLhorvzDm42 Development policies touched upon in items 2-6 is what I'd invite to discuss on the BoF. Thank you. Alexander You are wearing: [*] Distribution maintainer's hat [*] GCC developer's hat [*] GCC user's hat # Undefined behavior and compiler diagnostics 1. Some undefined behavior is relevant only at translation time, not execution time (for example: an unmatched ' or " character is encountered on a logical source line during tokenization). GCC typically issues a diagnostic when encountering such UB. Should GCC rather make use of the undefinedness in order to make the compiler simpler and faster? [*] Yes [*] No Details: _ 2. In some instances GCC is able to produce a warning for code that is certain to invoke undefined behavior at run time. Should GCC strive to diagnose that as much as practical, even at the cost of the compiler getting more complex? [*] Yes [*] No Details: _ 3. Sometimes GCC is also able to issue a warning for code that is likely (but not certain) to invoke undefined behavior. As such warnings may have false positives, should GCC nevertheless try to issue them too, where practical? [*] Yes [*] No Details: _ 4. When GCC assumes absence of undefined behavior in optimization, it leads to "surprising" transformations. This is generally not reportable to the user; however, -Waggressive-loop-optimization was added for one such case. If you are familiar with that flag, would you say overall it was worth it, and more warnings in that spirit would be nice to have? [*] Yes [*] No Details: _ # Undefined behavior and compiler optimizations 5. When GCC optimizations encounter code that is certain to invoke undefined behavior, they do not react consistently: at the moment we have a wide range of behaviors, like not transforming the code at all, or replacing it with a trap instruction. Should GCC apply one tactic consistently, and if so, which? [*] Yes [*] No Details: _ 6. Some GCC optimization/analysis functionality assumes absence of UB, and cannot detect that code invokes undefined behavior. Should GCC prefer to assume presence of UB in analysis, which would allow to diagnose it or transform to runtime trap? [*] Yes [*] No Details: _
Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32
On Tue, Aug 21, 2018 at 9:52 AM, Rainer Emrich wrote: > Bootstrap is done with msys2 on Windows 7. For the testsuite results see > https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html Did you get SEH to work?
Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32
вт, 21 авг. 2018 г. в 20:46, NightStrike : > On Tue, Aug 21, 2018 at 9:52 AM, Rainer Emrich > wrote: > > Bootstrap is done with msys2 on Windows 7. For the testsuite results see > > https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html > > Did you get SEH to work? > MSYS2 have 64-bit GCC-8.2.0 toolchain in repo with SEH. 32-bit GCC build fail because of gnat segfaults
Re: Relocation Truncated to Fit: R_X86_64_PC32
On Mon, Jul 30, 2018 at 6:28 PM, Jonathan Wakely wrote: > On Mon, 30 Jul 2018 at 22:53, R0b0t1 wrote: >> >> On Mon, Jul 30, 2018 at 4:32 PM, R0b0t1 wrote: >> > Hello list, >> > >> > I have been told to solve this error I should pass -fPIC and >> > -mcmodel=large. I believe I understand the reasons. >> > >> > Sadly the error persists. Any advice? >> > >> >> It looks like I may have to recompile everything with -mcmodel=large >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46125) which is rather >> inconvenient in this case. >> >> If anyone has more information it may help. > > Your question is off-topic on the gcc list, I've CC'd the gcc-help > list where it belongs. Please remove gcc@ from any further replies. > > -fPIC should be enough, you shouldn't need to change the code model. Hello everyone, I'm adding a message to the gcc-devel list because I'd appreciate some help figuring out if this is a bug. The issue was that I was missing a linking directive to a library (-lwinpr). The message does not seem to be reasonable in this context. I've also encountered it when supplying potentially nonsensical arguments (e.g. link in this dynamic library statically). Cheers, R0b0t1
Re: Relocation Truncated to Fit: R_X86_64_PC32
On Tue, 21 Aug 2018 at 19:43, R0b0t1 wrote: > Hello everyone, I'm adding a message to the gcc-devel list because I'd > appreciate some help figuring out if this is a bug. The issue was that > I was missing a linking directive to a library (-lwinpr). The message > does not seem to be reasonable in this context. I've also encountered > it when supplying potentially nonsensical arguments (e.g. link in this > dynamic library statically). So wouldn't that be a linker error, not one that comes from GCC, and so still off-topic?
Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32
On Tue, Aug 21, 2018 at 2:05 PM, Alexey Pavlov wrote: > > вт, 21 авг. 2018 г. в 20:46, NightStrike : >> >> On Tue, Aug 21, 2018 at 9:52 AM, Rainer Emrich >> wrote: >> > Bootstrap is done with msys2 on Windows 7. For the testsuite results see >> > https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html >> >> Did you get SEH to work? > > > MSYS2 have 64-bit GCC-8.2.0 toolchain in repo with SEH. > 32-bit GCC build fail because of gnat segfaults Can either of you try trunk to see if SEH works?
