RE: Google Summer of Code 2018: Call for mentors and ideas
Hi Martin, Frankly speaking I believe that students who discussed topics on mailing list might eventually just decide that they were too challenging for them and also competition appeared too difficult. As far as I remember student can only pick few organizations and maybe they just decided to pick some other projects where they expected higher chance of success. After all, as you wrote, it is students work to come up with good projects. Nevertheless, I'd suggest keeping discussions regarding GSoC projects, that took place in mailing list in wiki (as a summary or direct links) for future reference if someone would like to better understand how some elements work in GCC or would like to continue those works. Without any external link I'm afraid it might get lost in the mailing list soon. >From my personal point of view I think you did a great work with handling all >communication regarding GSoC participation and I believe you are a perfect candidate for admin role next year. Sebastian > -Original Message- > Sent: Thursday, March 29, 2018 7:08 PM > Subject: Re: Google Summer of Code 2018: Call for mentors and ideas > > Hi, > > I was wondering how much I should announce publicly about GSoC proposals > since students are not supposed to know in advance that we want any particular > one before they are officially accepted or not by google, but I hope I will > not > overstep any line by saying the following: > > (I am willing to invite any GCC contributer among the mentors, then you can > look at the proposals at the GSoC "dashboard" website. You need gmail account > for that, however.) > > > On Thu, Mar 29 2018, Joseph Myers wrote: > > Now the student application deadline has, I understand, passed, how do > > we go about collectively deciding which are the best proposals to > > request slots for? > > GCC has received 11 proposals for projects, but 7 of them were clearly > unsuitable (two were completely blank, one was a link to a live google > document with the string "WIP" in it, one contained only a short CV of the > applicants, one was three lines suggesting we use a "linked list" > and "hash tags" for memory management, there was also a proposal for driver > able to compile C and python in different sections of a single file, and one > proposal was just spam or an elaborate report on some past java project, I > cannot tell) and 2 were inferior to the point that I also decided they should > not > be considered. None of these two was discussed on the mailing list and both > were basically copied text from an (outdated) wiki page. > > The remaining two are strong candidates, both proposals were discussed at > length here on the mailing list and so I asked for two student slots. > My plan forward is basically to sincerely hope that we get two. If we get > only > one (IIRC we will know on April 10th), I will bring this question up here > (but let's > just toss a coin in that case). > > Generally speaking, I am somewhat disappointed that one or two topics that > were also discussed on the mailing list did not eventually turn up among the > proposals. I should have probably pinged one student and perhaps also two gcc > developers a bit in order to make them come up with something. It also did > not > help that I was traveling to an important meeting in the US last week (and I > had > much less time for email than I thought I would). Nevertheless, it is mostly > students' responsibility to come up with good projects and there is only so > much > we can do about it. However, if the community decides I should be the admin > also next year, I believe I will be able to organize it slightly better. > > Martin
GCC-8 branching
Hi, I'd like to ask what is the expected date for GCC branching to GCC-8 release version? I'm mostly interested because I'd like to know when it'll be ok again to add new features? Or are we still able to add them? Thanks, Sebastian
RE: What is dump_file in gcc ?
> Subject: What is dump_file in gcc ? > > I have ever seen "fprintf(dump_file,"something writes into dump_file") many > times. > I want to know what dump_file is and how can I check its content ? I'm not 100% sure, but my best guess is that this is related to GCC dumps, e.g. related to passes. You can do -fdump-- where type can be e.g. rtl and pass the pass for which you want to gather information. I suppose there is more to those dumps, but this should get you started. Sebastian > >
Question regarding preventing optimizing out of register in expansion
Hi, I'd appreciate if someone could advise me in builtin expansion I'm currently writing. High level description for what I want to do: I have 2 operands in my builtin. First I set register (reg1) with value from operand1 (op1); Second I call my instruction (reg1 is called implicitly and updated); At the end I'm setting operand2 (op2) with value from reg1. Simplified implementation in i386.c I have: reg1 = gen_reg_rtx (mode); emit_insn (gen_rtx_SET (reg1, op1); emit_clobber (reg1); emit_insn (gen_myinstruction ()); emit_insn (gen_rtx_SET (op2,reg1)); Everything works fine for -O0, but when I move to higher level optimizations setting value into reg1 (lines before emit_clobber) are optimized out. I already tried moving emit_clobber just after assignment but it doesn't help. Could you please suggest how I can prevent it from happening? Thanks, Sebastian
RE: Question regarding preventing optimizing out of register in expansion
Thank you very much! Your suggestions helped me figure this out. Sebastian -Original Message- From: Nathan Sidwell [mailto:nathanmsidw...@gmail.com] On Behalf Of Nathan Sidwell Sent: Thursday, June 21, 2018 1:43 PM To: Peryt, Sebastian ; gcc@gcc.gnu.org Subject: Re: Question regarding preventing optimizing out of register in expansion On 06/21/2018 05:20 AM, Peryt, Sebastian wrote: > Hi, > > I'd appreciate if someone could advise me in builtin expansion I'm currently > writing. > > High level description for what I want to do: > > I have 2 operands in my builtin. IIUC you're defining an UNSPEC. > First I set register (reg1) with value from operand1 (op1); Second I > call my instruction (reg1 is called implicitly and updated); Here is your error -- NEVER have implicit register settings. The data flow analysers need accurate information. > Simplified implementation in i386.c I have: > > reg1 = gen_reg_rtx (mode); > emit_insn (gen_rtx_SET (reg1, op1); > emit_clobber (reg1); At this point reg1 is dead. That means the previous set of reg1 from op1 is unneeded and can be deleted. > emit_insn (gen_myinstruction ()); This instruction has no inputs or outputs, and is not marked volatile(?) so can be deleted. > emit_insn (gen_rtx_SET (op2,reg1)); And this is storing a value from a dead register. You need something like: rtx reg1 = force_reg (op1); rtx reg2 = gen_reg_rtx (mode); emit_insn (gen_my_insn (reg2, reg1)); emit insn (gen_rtx_SET (op2, reg2)); your instruction should be an UNSPEC showing what the inputs and outputs are. That tells the optimizers what depends on what, but the compiler has no clue about what the transform is. nathan -- Nathan Sidwell
RE: Question regarding preventing optimizing out of register in expansion
After some more digging and adjusting I found additional cases that are optimizing out registers thus I decided to continue this thread to keep discussion compact. With some changes simplified implementation of my expansion is as follows: tmp_op0 = gen_reg_rtx (mode); emit_move_insn (tmp_op0, op0); tmp_op1 = gen_reg_rtx (mode); emit_move_insn (tmp_op1, op1); // This is important part reg = gen_rtx_REG(wide_mode, XMM2_REG); emit_insn (gen_rtx_SET (reg, tmp_op1)); emit_insn (gen_myinsn(op2, reg)); emit_insn (gen_rtx_SET (tmp_op0, reg)); And my md is as follows: (define_insn "myinsn" [(unspec [(match_operand:SI 0 "register_operand" "r") (match_operand:V4SI 1 "vector_operand")] UNSPEC_MYINSN) (clobber (reg:V4SI XMM2_REG))] "TARGET_MYTARGET" "instr\t%0" [(set_attr "type" "other")]) This is working like a charm when built with any optimization level producing something like this: movdqu %eax, %xmm2 instr %edx movups %xmm2, %eax Unfortunately, when I build it with additional -mavx2 or -mavx512f first move (from reg to xmm2) is optimized out. I'm using those extra flags because I also want to use YMM2 and ZMM2 in my instruction. Does anyone have idea why might such thing happen? And how this can be overcome? Thanks, Sebastian > -Original Message- > Subject: Re: Question regarding preventing optimizing out of register in > expansion > > On 06/21/2018 05:20 AM, Peryt, Sebastian wrote: > > Hi, > > > > I'd appreciate if someone could advise me in builtin expansion I'm currently > writing. > > > > High level description for what I want to do: > > > > I have 2 operands in my builtin. > > IIUC you're defining an UNSPEC. > > > First I set register (reg1) with value from operand1 (op1); Second I > > call my instruction (reg1 is called implicitly and updated); > > Here is your error -- NEVER have implicit register settings. The data flow > analysers need accurate information. > > > > Simplified implementation in i386.c I have: > > > > reg1 = gen_reg_rtx (mode); > > emit_insn (gen_rtx_SET (reg1, op1); > > emit_clobber (reg1); > > At this point reg1 is dead. That means the previous set of reg1 from > op1 is unneeded and can be deleted. > > > emit_insn (gen_myinstruction ()); > > This instruction has no inputs or outputs, and is not marked volatile(?) > so can be deleted. > > > emit_insn (gen_rtx_SET (op2,reg1)); > > And this is storing a value from a dead register. > > You need something like: >rtx reg1 = force_reg (op1); >rtx reg2 = gen_reg_rtx (mode); >emit_insn (gen_my_insn (reg2, reg1)); >emit insn (gen_rtx_SET (op2, reg2)); > > your instruction should be an UNSPEC showing what the inputs and outputs > are. That tells the optimizers what depends on what, but the compiler > has no clue about what the transform is. > > nathan > -- > Nathan Sidwell
RE: Question regarding preventing optimizing out of register in expansion
> Subject: Re: Question regarding preventing optimizing out of register in > expansion > > On 6/26/18 4:05 AM, Peryt, Sebastian wrote: > > With some changes simplified implementation of my expansion is as follows: > > tmp_op0 = gen_reg_rtx (mode); > > emit_move_insn (tmp_op0, op0); > > You set tmp_op0 here, and then > > > > emit_insn (gen_rtx_SET (tmp_op0, reg)); > > You set it again here without ever using it above, so it's dead code, which > explains why it's removed. Oh My bad - I oversimplified my code. Now I can see it. This should be more appropriate: tmp_op0 = gen_reg_rtx (mode); emit_move_insn (tmp_op0, op0); tmp_op1 = gen_reg_rtx (mode); emit_move_insn (tmp_op1, op1); // This is important part reg = gen_rtx_REG(wide_mode, XMM2_REG); op3 = gen_rtx_PLUS (mode, tmp_op1, GEN_INT (128)); emit_insn (gen_rtx_SET (reg, op3)); emit_insn (gen_myinsn(op2, reg)); op3 = gen_rtx_PLUS (mode, tmp_op0, GEN_INT (128)); emit_insn (gen_rtx_SET (op3, reg)); Also I'd like to one more time point out that without additional -mavx or -mavx2 I'm getting expected register moves before and after my instr. With those options only *after*. This is the part that I don't get especially - why. > > Peter >
