Re: Status of m32c target?
On 01/19/2018 10:14 AM, Jeff Law wrote: cc0 needs to die. That doesn't mean that any particular target needs to be dropped -- it just means that someone has to step forward to do the conversion. Unifying two parallel threads: might this be a good project for GSoC? -Sandra
Re: Status of m32c target?
On Fri, Jan 19, 2018 at 07:58:02PM +0100, Eric Botcazou wrote: > > - cc0 does a good job and did always a good job in the past. In the > > years I contributed to avr, there hasn't been a single cc0 flaw (all the > > few, minor cc0-related issues were avr BE issues). cc0 does not do a good job at all for many targets. And for the targets where it has acceptable results, the more modern representation works better. > cc0 does inhibit RTL optimizations because of the implementation constraints > it imposes, most notably the non-separation of CC setters and users. Yes. And some 40 .c files need specific handling of CC0, separately of everything else. It's a maintenance problem (and in many cases we say "cc0? Just give up." btw). I believe we have now spent more than twenty years transitioning away from cc0 (history is a bit hard to search that far away). Maybe this is enough. Segher
Re: Status of m32c target?
> Yes, I know that CCmode can represent condition code. But just the fact > that it can represent it doesn't make it superior or cc0 inferior or > bad. Having different representations for the same thing has also its > obvious upsides (think of different representations in maths or > physics), and in the present case one has the choice between an explicit > RTL representation and an implicit (w.r.t. to RTL) one. Different representations in maths are interesting only if you can easily go back and forth between them, so I don't think the analogy is valid here. > - cc0 does a good job and did always a good job in the past. In the > years I contributed to avr, there hasn't been a single cc0 flaw (all the > few, minor cc0-related issues were avr BE issues). cc0 does inhibit RTL optimizations because of the implementation constraints it imposes, most notably the non-separation of CC setters and users. > - No improvements of generated code are expected. avr won't benefit > from separating comparisons from branches (no scheduling). See above. Moreover, it is easy to implement a minimal form of scheduling to hide the latency of the loads (assuming some AVR processors are pipelined), in which case CCmode will give you a performance bonus. -- Eric Botcazou
Re: Google Summer of Code 2018: Call for mentors and ideas
On January 19, 2018 5:34:35 PM GMT+01:00, Joseph Myers wrote: >On Fri, 19 Jan 2018, Martin Jambor wrote: > >> Hi Joseph, >> >> On Wed, Jan 17 2018, Joseph Myers wrote: >> > On Wed, 17 Jan 2018, Martin Jambor wrote: >> > >> >> 3?) Joseph Myers brought up idea to do "built-in functions for TS >18661 >> >> floating-point functions - which has the feature that there >are a >> >> lot of similar built-in functions for C99/C11 functions to >serve as >> >> a guide for how to implement things)" ...Joseph, would you be >> >> willing to mentor it? >> > >> > Yes, provided at least one other mentor is available as well as I >may not >> > be around all the time during the GSoC period, including one of the > >> > evaluation periods. >> >> Thank you (but please think who that other mentor could be :-) > >Well, anyone reasonably familiar with the workings of built-in >functions >(from builtins.def through to defining corresponding insn patterns). >Floating-point expertise not required. I can co - mentor. Richard.
Re: Status of m32c target?
On 01/19/2018 06:33 AM, Georg-Johann Lay wrote: > On 13.01.2018 00:07, Joseph Myers wrote: >> On Fri, 12 Jan 2018, Jeff Law wrote: >> >>> I was going to suggest deprecation for gcc-8 given how badly it was >>> broken in gcc-7 and the lack of maintenance on the target. >> >> While we're considering deprecations, what happened to the idea of >> setting >> a timescale by which cc0 targets need to be converted away from cc0 or be >> removed? > > I still don't quite get why cc0 is considered to be so bad. Just the > fact that the big targets don't use it doesn't make it useless. It's a significant maintenance burden for anyone working in RTL. cc0 targets have special rules that must be followed, but are easily forgotten. cc0 handling does not exist in LRA and it's not going to be added to LRA. So supporting cc0 ports is also blocking removal of reload, which again is a major maintenance burden. Worse yet, there are interactions between those rules, FP support, and exception handling which fundamentally can't be fixed. We've lazily faulted in work-arounds for these problems as they've popped up, but that's the best we can do now -- layer hack on hack to work around fundamental problems with a broken design (cc0). cc0 needs to die. That doesn't mean that any particular target needs to be dropped -- it just means that someone has to step forward to do the conversion. Jeff
Re: Google Summer of Code 2018: Call for mentors and ideas
On Fri, 19 Jan 2018, Martin Jambor wrote: > Hi Joseph, > > On Wed, Jan 17 2018, Joseph Myers wrote: > > On Wed, 17 Jan 2018, Martin Jambor wrote: > > > >> 3?) Joseph Myers brought up idea to do "built-in functions for TS 18661 > >> floating-point functions - which has the feature that there are a > >> lot of similar built-in functions for C99/C11 functions to serve as > >> a guide for how to implement things)" ...Joseph, would you be > >> willing to mentor it? > > > > Yes, provided at least one other mentor is available as well as I may not > > be around all the time during the GSoC period, including one of the > > evaluation periods. > > Thank you (but please think who that other mentor could be :-) Well, anyone reasonably familiar with the workings of built-in functions (from builtins.def through to defining corresponding insn patterns). Floating-point expertise not required. -- Joseph S. Myers jos...@codesourcery.com
Re: Google Summer of Code 2018: Call for mentors and ideas
Hi Andi, On Thu, Jan 18 2018, Andi Kleen wrote: > Martin Jambor writes: >> >> Therefore I would like to ask all seasoned GCC contributors who would >> like to mentor a GSoC student to send a reply to this thread with their >> idea for a project. If you have an idea but you do not want to be a >> mentor then I will consider it only if it is really interesting, really >> specific (e.g. improving -O2 -g *somehow* is not specific) and I would >> have to be reasonably confident I'd find a good mentor for it. So far I >> have the following ideas from the IRC discussion: > > Here's an idea: > > fuzzers like csmith are fairly good at finding compiler bugs. But they > only generate standard C, but no extensions. gcc has many extensions, > which are not covered. It would be good to extend a fuzzer like csmith > to fuzz extensions like OpenMP, __attributes__, vector > extensions, etc. Then run the fuzzer and report > compiler bugs. > > I'm not a seasoned gcc contributor, but would be willing to mentor > such a project. > Thanks a lot, project noted, it is an interesting idea. You are definitely seasoned enough as far as I am concerned. Martin
Re: Google Summer of Code 2018: Call for mentors and ideas
Hi, On Thu, Jan 18 2018, Joseph Myers wrote: > On Thu, 18 Jan 2018, Eric Gallager wrote: > >> Would it make sense to recycle old GSoC projects that never got >> completed? in principle that is definitely possible, but... >>I'm wondering about the "replace libiberty with gnulib" one > > I'd like to see that finished, but I'm not convinced it makes a good GSoC > project, given how it involves tricky portability and build system issues > and the need to test for lots of different configurations including > Canadian crosses. It would really need someone particularly interested in > that area, and a build machinery maintainer actively involved. > ...Joseph's concern sounds very valid to me. Martin
Re: Google Summer of Code 2018: Call for mentors and ideas
On Fri, Jan 19 2018, Martin Jambor wrote: > Hi, > > On Thu, Jan 18 2018, Martin Liška wrote: >> On 01/17/2018 06:54 PM, Martin Jambor wrote: >> > ... >>> >>> 2) Martin Liška is willing to mentor either: >>>2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197 >>>but it gives me a 404 error) or its prototype, or >>>2b) bash code completion like: >>> >>> http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html >>>but frankly I am afraid it is too small to be a GSoC project, or >>>2c) textual representation of LTO stream a.k.a. lto-dump tool >> >> If there's an interest, I can specify in more detail these topics. > > First, we'll need (just) enough info to make the idea attractive for > students. Then they will need to write a project proposal with > milestones and stuff > (https://google.github.io/gsocguides/student/writing-a-proposal). I am > not sure how involved we will be at that point, but perhaps it is a good > idea to think about milestones anyway. > >> Note that >> David Malcolm is also interested in 2b) and he's willing to be co-mentor. >> The topic 2b) can be enlarged to an overhaul of option handling, with >> possible >> rewritten of current AWK scripts. > > I am still a bit sceptical about the b option. IIRC there was an > objection on the IRC that rewriting AWK scripts would require extensive > testing in a wide variety of often obscure environments. That may make > it ill-suited for GSoC. But well... I am not strictly against it, but > we may need to set the expectations accordingly ...which may not make it > attractive neither for students not for Google. > Ah no, I confused myself. That was Joseph's issue with the idea of replacing libiberty with gnulib. The problem with this one was getting a consensus to move away from AWK to python which would introduce a new dependency of the gcc project. Someone experienced (and determined) from the community would have to drive that decision, we may not expect a newcomer, let a alone a student, to do it. Sorry for the confusion, Martin
Re: Google Summer of Code 2018: Call for mentors and ideas
Hi, On Thu, Jan 18 2018, Martin Liška wrote: > On 01/17/2018 06:54 PM, Martin Jambor wrote: > ... >> >> 2) Martin Liška is willing to mentor either: >>2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197 >>but it gives me a 404 error) or its prototype, or >>2b) bash code completion like: >>http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html >>but frankly I am afraid it is too small to be a GSoC project, or >>2c) textual representation of LTO stream a.k.a. lto-dump tool > > If there's an interest, I can specify in more detail these topics. First, we'll need (just) enough info to make the idea attractive for students. Then they will need to write a project proposal with milestones and stuff (https://google.github.io/gsocguides/student/writing-a-proposal). I am not sure how involved we will be at that point, but perhaps it is a good idea to think about milestones anyway. > Note that > David Malcolm is also interested in 2b) and he's willing to be co-mentor. > The topic 2b) can be enlarged to an overhaul of option handling, with possible > rewritten of current AWK scripts. I am still a bit sceptical about the b option. IIRC there was an objection on the IRC that rewriting AWK scripts would require extensive testing in a wide variety of often obscure environments. That may make it ill-suited for GSoC. But well... I am not strictly against it, but we may need to set the expectations accordingly ...which may not make it attractive neither for students not for Google. Martin
Re: Google Summer of Code 2018: Call for mentors and ideas
Hi Joel, On Wed, Jan 17 2018, Joel Sherrill wrote: > On 1/17/2018 11:54 AM, Martin Jambor wrote: >> Hi, >> >> following a discussion at IRC about an upcoming deadline to register GCC >> as an independent organization for Google Summer of Code 2018 (GSoC), I >> have volunteered to serve as the org-admin for GCC if: >> >>- there is not another volunteer (so step up if you are!), >> >>- the community does not object (so let me and/or the steering >> committee know if you think I am not the right person!), and >> >>- we have at least 4 good project ideas together(!) with willing >> mentors by next Monday January 22 (the deadline is on Tuesday). I >> will be very happy if we have more. >> >> There are project ideas on our GSoC wiki page >> (https://gcc.gnu.org/wiki/SummerOfCode) but those are not associated >> with a willing mentor and it is basically an idea dump, it is often not >> clear how up to date the proposals are and often they are just a bit too >> terse. > > I will put a plug for a GCC related project on the RTEMS wish list that > is on our GSoC Open Projects list. It is part of a broader project. > We need someone who understands gcov for. We would consider you a > co-mentor but I think the support would be light. I think it would > be better described as a subject matter expert helping on an issue. > > We have a tool that aggregates the output of simulator trace logs > and generates coverage reports directly. It can also generate > gcov output but there are some anomalies when gcov generates reports > from our input that don't match the truth of the traces. > > We just need someone who can explain what is wrong so it can be fixed. I see. However, since this would be an RTEMs project from Google's point of view, I would suggest that you then email your questions (or requests for co-mentorship) to the gcc mailing list independently (i.e. without my involvement) and CC the maintainers and people who have touched the corresponding files a lot recently. (Unless you think I specifically can be of help somehow, of course). Thanks, Martin > >> >> Therefore I would like to ask all seasoned GCC contributors who would >> like to mentor a GSoC student to send a reply to this thread with their >> idea for a project. If you have an idea but you do not want to be a >> mentor then I will consider it only if it is really interesting, really >> specific (e.g. improving -O2 -g *somehow* is not specific) and I would >> have to be reasonably confident I'd find a good mentor for it. So far I >> have the following ideas from the IRC discussion: >> >> 1) Jakub is willing to mentor (with someone from GDB but I reckon that >> we will find someone) a project implementing OMPD. >> >> 2) Martin Liška is willing to mentor either: >> 2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197 >> but it gives me a 404 error) or its prototype, or >> 2b) bash code completion like: >> >> http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html >> but frankly I am afraid it is too small to be a GSoC project, or >> 2c) textual representation of LTO stream a.k.a. lto-dump tool >> >> 3?) Joseph Myers brought up idea to do "built-in functions for TS 18661 >> floating-point functions - which has the feature that there are a >> lot of similar built-in functions for C99/C11 functions to serve as >> a guide for how to implement things)" ...Joseph, would you be >> willing to mentor it? >> >> Please send me your idea for a project you'd like to mentor. Also feel >> free to comment on other proposals including those above. I intend to >> put successful project ideas from this thread into a prominent position >> on the wiki page. Remember, I want at least four plausible ones with >> willing mentors until Monday, January 22nd 23:59 CET. >> >> All sorts of information are available from the GSoC web page at >> https://summerofcode.withgoogle.com/, for example guides for mentors are >> at >> https://developers.google.com/open-source/gsoc/resources/guide#mentor_manual >> >> Thanks, >> >> Martin >>
Re: Status of m32c target?
On 13.01.2018 00:07, Joseph Myers wrote: On Fri, 12 Jan 2018, Jeff Law wrote: I was going to suggest deprecation for gcc-8 given how badly it was broken in gcc-7 and the lack of maintenance on the target. While we're considering deprecations, what happened to the idea of setting a timescale by which cc0 targets need to be converted away from cc0 or be removed? I still don't quite get why cc0 is considered to be so bad. Just the fact that the big targets don't use it doesn't make it useless. Yes, I know that CCmode can represent condition code. But just the fact that it can represent it doesn't make it superior or cc0 inferior or bad. Having different representations for the same thing has also its obvious upsides (think of different representations in maths or physics), and in the present case one has the choice between an explicit RTL representation and an implicit (w.r.t. to RTL) one. The target I am familiar with is avr, and for that particular target, I cannot see a single benefit: - cc0 does a good job and did always a good job in the past. In the years I contributed to avr, there hasn't been a single cc0 flaw (all the few, minor cc0-related issues were avr BE issues). From my experience, if some middle-end bits flaw for a what-the-dickens-is-xxx-target, then that target is left behind and has to hack the backend to surmount the middle-end flaw (like for reload or all the other FIXMEs you'll find). I wouldn't expect that anyone would fix CCmode shortcomings if some of these targets had trouble with it. And IIUC one of the posts from above, m32c is considered to be kicked out because of reload bugs. - No improvements of generated code are expected. avr won't benefit from separating comparisons from branches (no scheduling). - Likewise for insn splitting: If the avr port could benefit more from splitting, then such splitting would have to be performed before register allocation -- which is not supported as LRA is restricted to cases that don't clobber CC (which is not possible for avr), and reload will also die soon IIUC. Hence any CCmode implementation for avr will jump in after RA, even if reload might still be in use. - Currently the best instruction sequence is printed during asm out. Often, there is a multitude of different sequences that could perform the same task, and the best (usually w.r.t. length) is chosen ad doc. The cc0 setting and insn length computation follows the sequence, i.e. there are implicit assertions between printed code, insn lengths and cc0 effect. All this is in a single place, cf. avr_out_plus all its callees like avr_out_plus_1. Usually, it is not possible to describe the conditions for specific sequences on RTL or constraint level (would need to filter depending on cartesian product over all constraints, and this is not possible because not allowed in insn conditions). Switching to CCmode would basically require to throw avr into the dust bin and start the backend from scratch, at least considerable parts of c and md. Even if switching to a clobbers-all solution is feasible, this will result in performance drop, and fixing that will likely be no easy task (if possible with a reasonable effort at all) and greatly destabilize the backend. Actually, LLVM has an evolving avr backend. It's far from being mature and less stable and optimizing than gcc's. But instead of putting work into a dead horse (at least re. avr) like gcc with strong tendencies of self-destruction (which removing cc0 is, IMO), it seems much more reasonable to switch to an infrastructure that's more friendly to such architectures and not in the decline. In my option, one of the great upsides of GCC is that it supports so many targets, many deeply embedded, mature targets amongst them. With that background, it may very well make sense to have considerably different approaches to the same problem. And most of cc0 code is in final and a few parts that keep comparisons and branches together. So kicking out cc0 doesn't seem to bring a maintenance boost, either... Johann
Re: Google Summer of Code 2018: Call for mentors and ideas
Hi Joseph, On Wed, Jan 17 2018, Joseph Myers wrote: > On Wed, 17 Jan 2018, Martin Jambor wrote: > >> 3?) Joseph Myers brought up idea to do "built-in functions for TS 18661 >> floating-point functions - which has the feature that there are a >> lot of similar built-in functions for C99/C11 functions to serve as >> a guide for how to implement things)" ...Joseph, would you be >> willing to mentor it? > > Yes, provided at least one other mentor is available as well as I may not > be around all the time during the GSoC period, including one of the > evaluation periods. Thank you (but please think who that other mentor could be :-) > > (The outline I put on the wiki page is: > > GCC supports built-in functions for math.h and complex.h functions in > the C99/C11 standards (both folding calls for constant arguments, and > expanding inline when the processor supports appropriate functionality). > More such functions have been added in ISO/IEC TS 18661, supporting > features of IEEE 754-2008. It would be useful to have built-in functions > for those, both folding for constant arguments, and expanding inline > where appropriate (e.g. for roundeven and the functions rounding result > to narrower type, on some processors; roundeven can be inlined on x86 > for SSE4.1 and later, and the narrowing functions on IA64 and POWER8, > for example). Existing built-in functions would provide a guide for how > to do this. > > This project has the feature that there are lots of smaller subprojects > each of which would be a useful enhancement to GCC, so a student could > start off with e.g. roundeven built-in functions, closely following how > existing code handles round / floor / ceil / trunc, before going on to > more complicated functions such as the narrowing ones or the fromfp > functions - with scope for functions from TS 18661-3 and TS 18661-4 if > they run out of useful functions from TS 18661-1. If a student were > interested I could provide more detailed lists of possible subprojects.) That is a very nice feature indeed, Martin
