Re: Bugzilla vs 5.0 milestone
On Thu, Mar 26, 2015 at 1:10 AM, Paolo Carlini wrote: > Hi, > > sorry if I missed part of the discussion about the new numbering scheme and > the answer to my question is already clear from that: why we do have 5.0 as > Milestone in Bugzilla instead of 5.1?!? Yeah, well ... details. We chose to not mass-change those after the numbering scheme was agreed to. But yes, technically the milestones should be 5.1 now. Richard. > Thanks, > Paolo.
Re: Bugzilla vs 5.0 milestone
On Thu, Mar 26, 2015 at 09:36:30AM +0100, Richard Biener wrote: > On Thu, Mar 26, 2015 at 1:10 AM, Paolo Carlini > wrote: > > sorry if I missed part of the discussion about the new numbering scheme and > > the answer to my question is already clear from that: why we do have 5.0 as > > Milestone in Bugzilla instead of 5.1?!? > > Yeah, well ... details. We chose to not mass-change those after the numbering > scheme was agreed to. But yes, technically the milestones should be 5.1 now. Supposedly if we just rename the 5.0 milestone to 5.1 milestone and update the queries it could work. Though, 5.0 milestone isn't completely meaningless, it means plan to fix it already before the release. Jakub
Re: Bugzilla vs 5.0 milestone
Hi, On 03/26/2015 09:52 AM, Jakub Jelinek wrote: On Thu, Mar 26, 2015 at 09:36:30AM +0100, Richard Biener wrote: On Thu, Mar 26, 2015 at 1:10 AM, Paolo Carlini wrote: sorry if I missed part of the discussion about the new numbering scheme and the answer to my question is already clear from that: why we do have 5.0 as Milestone in Bugzilla instead of 5.1?!? Yeah, well ... details. We chose to not mass-change those after the numbering scheme was agreed to. But yes, technically the milestones should be 5.1 now. Ok, I understand ;) Supposedly if we just rename the 5.0 milestone to 5.1 milestone and update the queries it could work. Though, 5.0 milestone isn't completely meaningless, it means plan to fix it already before the release. In fact I had the same thought, but I find annoying the inconsistency with the old numbering scheme, where the identifiers of Milestones match releases. All in all, if you ask me, assuming the ask isn't too much annoying, I would be in favor of the renaming... Paolo.
Re: Bugzilla vs 5.0 milestone
Jakub Jelinek writes: > Though, 5.0 milestone isn't completely meaningless, it means plan to fix it > already before the release. That's true for all 5.1 milestone bugs as well. :-) Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Bugzilla vs 5.0 milestone
On Thu, Mar 26, 2015 at 10:15 AM, Andreas Schwab wrote: > Jakub Jelinek writes: > >> Though, 5.0 milestone isn't completely meaningless, it means plan to fix it >> already before the release. > > That's true for all 5.1 milestone bugs as well. :-) It would be "fix during development aka stage1-3" vs. "fix for 5.1" which we'd use during stage4 (where we also forgot to bump the patchlevel version to get trunk to GCC 5.0.1 as documented). Richard. > Andreas. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."
Re: Bugzilla vs 5.0 milestone
On Thu, Mar 26, 2015 at 10:19 AM, Richard Biener wrote: > On Thu, Mar 26, 2015 at 10:15 AM, Andreas Schwab wrote: >> Jakub Jelinek writes: >> >>> Though, 5.0 milestone isn't completely meaningless, it means plan to fix it >>> already before the release. >> >> That's true for all 5.1 milestone bugs as well. :-) > > It would be "fix during development aka stage1-3" vs. "fix for 5.1" > which we'd use > during stage4 (where we also forgot to bump the patchlevel version to get > trunk > to GCC 5.0.1 as documented). Which means the target milestone should be 6.0 while trunk is still 5.0.x and 6.0.1 while trunk is 6.0.0 and 6.1.0 while trunk is 6.0.1 and 6.2.0 while the gcc-6-branch is 6.1.1. Maybe that's too much continuous renaming? Richard. > > Richard. > >> Andreas. >> >> -- >> Andreas Schwab, SUSE Labs, sch...@suse.de >> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 >> "And now for something completely different."
Re: Question about Gimple FE
On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote: > I think the gimple front end project would be quite useful to gcc so I’d like > to do work on it this summer. > > The problem is, it seems the GIMPLE front end project hasn’t been active for > some time > and Diego Novillo told me it may not even make sense to use the same > codebase, but start from scratch. > > I’m not sure if I should pick it up where it left off or write another one > from scratch > > Could you give me some advice? I don't know the current codebase at all (unfortunately). I think it is useful to get yourself familiarized with it even if you start from scratch as it will get you to learn something about GIMPLE and about writing a frontend. Note that LTO support already is able to output everything needed to re-create GIMPLE thus from there you can also learn what is required to populate a GIMPLE representation. And LTO support might be used to create output that can be read by the GIMPLE frontend - the whole project feels like finding a textual form of the LTO bytecode (in some way). Note that it's always useful to ask such questions on the mailing list as there may be other people who can give useful input. Thus, CCed. Richard. > Yinsong >
Re: [gsoc] Generic addressing mode selection
Hi all, I've submitted my proposal to the GSoC website, it can be found here: [1] After hearing some ideas from Oleg, I decided to go with working on detecting and optimizing a few specific memory access patterns instead of implementing a PBQP solver. Any suggestions or comments are welcome. I read that it's necessary to have a copyright assignment filed with the Free Software Foundation to be able to contribute larger amounts of code to GCC. When would it be best to start applying for a copyright assignment (e.g. sometime during the community bonding period, or the coding period, or around now)? Best regards, Erik [1] http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/erikvarga/5676830073815040
Fixing inconsistent uses of address costs
Hi all, I'd like to attempt to make GCC's usage of costs in the backends consistent. We have a lot of different types: rtx costs, address costs, regmove costs, vector costs etc. Some of them are use in different units, compared against different types of costs and in general are a bit of a mess. For now I'd like to clean up address costs since they are actually not used as much as some other costs and seem to me to be a slightly simpler task. From what I can see, address costs i.e. the TARGET_ADDRESS_COST hook are used in 5 places overall: * fwprop.c: forward propagation tries to propagate an rtx into an address and compare the address cost of the old address and the one it wants to propagate into it and picks the most profitable. * postreload.c: Again, tries to replace an address with a new one and compares the two address costs and picks the most profitable. * tree-ssa-loop-ivopts.c: A bit more involved here. From what I can tell it is used to assign a cost to various addressing modes, but ends up comparing but in the computation_cost function adds/mixes the address cost with rtx costs. * Some targets use address costs as part of their calculation of rtx costs for, say, a memory access instruction. * The final and worst part is in loop-invariant.c in the create_new_invariant function that needs to get a feel for how 'cheap' an address is and for that it compares the address cost to a magic number 3. See the thread that introduced it at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01210.html. There are a few issues wiht the above usages: - The magic number in loop-invariant.c was picked to help bwaves on x86 and makes no analytical sense for any other target. - Some targets use COSTS_N_INSNS units for their address costs, others use normal scalar units (every target that doesn't define the address costs hook ends up going through rtx costs which use COSTS_N_INSNS). I think this rather undermines the usage in tree-ssa-loop-ivopts.c which uses rtx costs in COSTS_N_INSNS and address costs interchangeably. An insight here is that address costs have two types of usage: 1. To compare two addresses and choose whether to replace one by the other (as in fwprop and postreload) 2. To give a metric of cheapness for use in loop optimisations. So I propose to split the two uses up. For the fwprop and postreload case introduce a hook that will take two addresses 'x' and 'y' and determine whether to substitute 'x' by 'y'. This can use address costs and allow the backend to do as deep comparison between two addresses as it could possibly want, unconstrained by the requirement to assign just a single number to each one individually and having the midend just pick the smallest number. We can call it something like TARGET_ADDRESS_PREFERABLE_P or something like that. Then get fwprop and postreload to use that to determine whether to substitute one address for another. What to do with the remaining address costs hook and its uses in tree-ssa-loop-ivopts and loop-invariant? Since tree-ssa-loop-ivopts uses the address costs interchangeably with rtx costs I think we should at least convert all address costs to use the same units: COSTS_N_INSNS. This raises a question: could we not just use rtx costs for the addresses? Someone with more familiarity with the code can correct me, but is the address cost usage in that file supposed to reflect the cost of computing the address outside of an addressing mode? If so, then shouldn't rtx costs be used? Conversely, if address costs are a measure of something different, surely we shouldn't be adding or comparing them with rtx costs, but rather create some two-dimensional structure to compare two rtx/address entities? (similarly to the rtx cost/latency calculations in expmed for the mult synthesis code). Then there's the usage in loop-invariant.c where the address cost number is compared with '3'. This is really not portable across targets. The code wants some measure of whether an address is 'cheap'. There could be various approaches on how to provide that. Could we enumerate across an rtx array of representatives of all possible addresses for a target sorted by the TARGET_ADDRESS_PREFERABLE_P hook above? Should we be asking the target to tell us which address type is cheap? In any case, it seems to me that the cheapest address in a target is something that only the target can tell, unless we agree on a universal meaning and unit of measurement for address costs. What do people think? Would this approach be worth pursuing if the above questions can be answered? From having a quick look at config/ I think that converting the targets to use COSTS_N_INSNS units would not be a controversial task as long as the midend usage of address costs is consistent. Thanks, Kyrill
Re: [gsoc] Generic addressing mode selection
On 03/26/2015 08:32 AM, Erik Varga wrote: Hi all, I've submitted my proposal to the GSoC website, it can be found here: [1] After hearing some ideas from Oleg, I decided to go with working on detecting and optimizing a few specific memory access patterns instead of implementing a PBQP solver. Any suggestions or comments are welcome. I read that it's necessary to have a copyright assignment filed with the Free Software Foundation to be able to contribute larger amounts of code to GCC. When would it be best to start applying for a copyright assignment (e.g. sometime during the community bonding period, or the coding period, or around now)? If you're looking at exploiting auto-inc addressing, others and myself have speculated that something built around straight-line-strength-reduction at the RTL level would be ideal for exploiting that capability. That may be more suitable for a GSOC project than tackling the entire space of address mode selections. jeff
Re: gcc wiki project
On Tue, 24 Mar 2015 13:16:26 +0100 Martin Jambor wrote: > Yes, I think that even just moving hopelessly outdated stuff to some > "Archive" section, looking at what is left and then perhaps > re-organizing the sections on the main page (and perhaps a few similar > ones) would be great, if you have the time and energy to do it. When I was trying to get some kind of "table of contents" of wiki, I ran into problem, that the relevant pages (i.e. the list of all pages, categories and several others) reply with timeout error. To workaround this, I wrote a simple crawler, which creates such list (it includes page title, last edit date, author and URL). Unfortunately, I the attached file was rejected by spam filter, so instead I'm posting a link to bitbucket repository: https://bitbucket.org/miyuki-chan/gcc_wiki_toc/downloads The list contains ~500 pages. It is an HTML file with several js-scripts, which allow to sort the list by columns mentioned above (title, last edit date and author). I hope it will help working on wiki. When I get some more free time, I'll also add a list of broken links. -- Regards, Mikhail Maltsev
Atomic operations and unaligned memory
The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says, --- typedef char B3[3]; _Atomic B3 obj2; An object will be promoted up to the next lock-free size in order to enable lock free operations, as long as it isn't already a documented lock free size. So obj2 will be promoted to a 4 byte object with whatever alignment is required in order to enable lock-free operations. --- But the implementation doesn't follow this. First, the above is rejected due to applying _Atomic to an array type. If we wrap the array in a struct, the resulting atomic object still has size 3 and alignment 1. Did the design change, or is this a bug? Jason
Re: Atomic operations and unaligned memory
On 03/26/2015 04:02 PM, Jason Merrill wrote: The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says, --- typedef char B3[3]; _Atomic B3 obj2; An object will be promoted up to the next lock-free size in order to enable lock free operations, as long as it isn't already a documented lock free size. So obj2 will be promoted to a 4 byte object with whatever alignment is required in order to enable lock-free operations. --- But the implementation doesn't follow this. First, the above is rejected due to applying _Atomic to an array type. If we wrap the array in a struct, the resulting atomic object still has size 3 and alignment 1. Did the design change, or is this a bug? That was the original grand plan... I vaguely recall a slow backing away from that as not being worth the trouble and previously unforeseen complications arising. I would hazard a guess that its now a design change. Andrew
Re: String literals in __init functions
(adding gcc@gcc.gnu.org) On Thu, 2015-03-26 at 14:40 -0700, Andrew Morton wrote: > On Thu, 26 Mar 2015 21:49:06 +0100 Mathias Krause > wrote: > > > Andrew, what's your opinion on such a patch set? Do you too think it's > > useful? Or do you share Ingo's fear about the additional maintenance > > burden? > > I don't think the burden would be t high, although it will mess the > code up a bit. I think it's overall a pretty low cost one-time pass that Mathias has nearly completely automated. Even if a future version of gcc implements string constants in specific sections, the code isn't difficult to understand or maintain for older versions. > The post-build checking for section reference mismatches will help, > although that seems to have got itself turned off (what happened > there?). I think the modprobe message works well. What do you think missing? > Did anyone ask the gcc developers? Not to my knowledge. > I'd have thought that a function-wide > __attribute__((__string_section__(foo)) > wouldn't be a ton of work to implement. Maybe not. Could some future version of gcc move string constants in a function to a specific section marked in a manner similar to what Andrew described above?
Re: String literals in __init functions
On Thu, 26 Mar 2015 14:58:40 -0700 Joe Perches wrote:
> > I'd have thought that a function-wide
> > __attribute__((__string_section__(foo))
> > wouldn't be a ton of work to implement.
>
> Maybe not.
>
> Could some future version of gcc move string constants
> in a function to a specific section marked in a manner
> similar to what Andrew described above?
One thing which might complexicate this is
void foo()
{
p("bar");
}
void __attribute__((__string_section__(.init.rodata)) zot()
{
p("bar");
}
It would be silly to create two instances of "bar".
Change it thusly:
#define __mark_str(str) \
({ static const char var[] __attribute__((__section__(".init.string")))
= str; var; })
void foo()
{
p("bar");
}
void zot()
{
p(__mark_str("bar"));
}
and we indeed get two copies of "bar".
It would be nice not to do that, but I guess that losing this
optimization is a reasonable compromise.
gcc-4.8-20150326 is now available
Snapshot gcc-4.8-20150326 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150326/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 221712 You'll find: gcc-4.8-20150326.tar.bz2 Complete GCC MD5=ee277453b0db3c9431c7edade21d1810 SHA1=28c5bbeb60feac18890dff4c74382f46e2030681 Diffs from 4.8-20150319 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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: [gsoc] Generic addressing mode selection
On Thu, 2015-03-26 at 09:43 -0600, Jeff Law wrote: > On 03/26/2015 08:32 AM, Erik Varga wrote: > > Hi all, > > > > I've submitted my proposal to the GSoC website, it can be found here: [1] > > After hearing some ideas from Oleg, I decided to go with working on > > detecting and optimizing a few specific memory access patterns instead > > of implementing a PBQP solver. > > Any suggestions or comments are welcome. > > I read that it's necessary to have a copyright assignment filed with > > the Free Software Foundation to be able to contribute larger amounts > > of code to GCC. When would it be best to start applying for a > > copyright assignment (e.g. sometime during the community bonding > > period, or the coding period, or around now)? > If you're looking at exploiting auto-inc addressing, others and myself > have speculated that something built around > straight-line-strength-reduction at the RTL level would be ideal for > exploiting that capability. > > That may be more suitable for a GSOC project than tackling the entire > space of address mode selections. As far as I understand the proposal, the goal is not to solve all AMS problems, but rather to lay the foundation for doing these kinds of optimizations and deal with a few assorted ones (most likely auto-mod will be a candidate). Thus, I think Erik's proposal sounds feasible, although I'd expect some of the allocations/priorities in the schedule to change during the project. But that's not something unusual to happen. Cheers, Oleg
Re: [gsoc] Generic addressing mode selection
On Thu, Mar 26, 2015 at 11:46 PM, Oleg Endo wrote: > On Thu, 2015-03-26 at 09:43 -0600, Jeff Law wrote: >> If you're looking at exploiting auto-inc addressing, others and myself >> have speculated that something built around >> straight-line-strength-reduction at the RTL level would be ideal for >> exploiting that capability. >> >> That may be more suitable for a GSOC project than tackling the entire >> space of address mode selections. > > As far as I understand the proposal, the goal is not to solve all AMS > problems, but rather to lay the foundation for doing these kinds of > optimizations and deal with a few assorted ones (most likely auto-mod > will be a candidate). Thus, I think Erik's proposal sounds feasible, > although I'd expect some of the allocations/priorities in the schedule > to change during the project. But that's not something unusual to > happen. That's right, the project's aim is to handle some specific access patterns and, in the process, build a framework that makes subsequent optimizations easier to write, not to tackle AMS in its entirety. I'll reword the proposal a bit to more accurately reflect this. Best regards, Erik
Re: Fixing inconsistent uses of address costs
On Thu, Mar 26, 2015 at 11:40 PM, Kyrill Tkachov wrote: > Hi all, > > I'd like to attempt to make GCC's usage of costs in the backends consistent. > We have a lot of different types: rtx costs, address costs, regmove costs, > vector costs etc. Some of them are use in different units, compared against > different types of costs and in general are a bit of a mess. For now I'd > like > to clean up address costs since they are actually not used as much as some > other costs and seem to me to be a slightly simpler task. > > From what I can see, address costs i.e. the TARGET_ADDRESS_COST hook are > used > in 5 places overall: > * fwprop.c: forward propagation tries to propagate an rtx into an address > and compare the address cost of the old address and the one it wants to > propagate into it and picks the most profitable. > > * postreload.c: Again, tries to replace an address with a new one and > compares > the two address costs and picks the most profitable. > > * tree-ssa-loop-ivopts.c: A bit more involved here. From what I can tell it > is > used to assign a cost to various addressing modes, but ends up comparing but > in the computation_cost function adds/mixes the address cost with rtx costs. > > * Some targets use address costs as part of their calculation of rtx costs > for, say, a memory access instruction. > > * The final and worst part is in loop-invariant.c in the > create_new_invariant > function that needs to get a feel for how 'cheap' an address is and for that > it compares the address cost to a magic number 3. See the thread that > introduced it at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01210.html. > > There are a few issues wiht the above usages: > - The magic number in loop-invariant.c was picked to help bwaves on x86 and > makes no analytical sense for any other target. > > - Some targets use COSTS_N_INSNS units for their address costs, others use > normal scalar units (every target that doesn't define the address costs hook > ends up going through rtx costs which use COSTS_N_INSNS). > I think this rather undermines the usage in tree-ssa-loop-ivopts.c which > uses > rtx costs in COSTS_N_INSNS and address costs interchangeably. > > An insight here is that address costs have two types of usage: > 1. To compare two addresses and choose whether to replace one by the other > (as in fwprop and postreload) > 2. To give a metric of cheapness for use in loop optimisations. > > So I propose to split the two uses up. For the fwprop and postreload case > introduce a hook that will take two addresses 'x' and 'y' and determine > whether to substitute 'x' by 'y'. This can use address costs and allow the > backend to do as deep comparison between two addresses as it could possibly > want, unconstrained by the requirement to assign just a single number to > each one individually and having the midend just pick the smallest number. > We can call it something like TARGET_ADDRESS_PREFERABLE_P or something like > that. Then get fwprop and postreload to use that to determine whether to > substitute one address for another. > > What to do with the remaining address costs hook and its uses in > tree-ssa-loop-ivopts and loop-invariant? Since tree-ssa-loop-ivopts uses > the address costs interchangeably with rtx costs I think we should at least > convert all address costs to use the same units: COSTS_N_INSNS. This raises > a question: could we not just use rtx costs for the addresses? Someone with > more familiarity with the code can correct me, but is the address cost usage > in that file supposed to reflect the cost of computing the address outside > of > an addressing mode? If so, then shouldn't rtx costs be used? Conversely, if > address costs are a measure of something different, surely we shouldn't be > adding or comparing them with rtx costs, but rather create some > two-dimensional > structure to compare two rtx/address entities? (similarly to the > rtx cost/latency calculations in expmed for the mult synthesis code). > > Then there's the usage in loop-invariant.c where the address cost number is > compared with '3'. This is really not portable across targets. The code > wants > some measure of whether an address is 'cheap'. There could be various > approaches on how to provide that. > Could we enumerate across an rtx array of representatives of > all possible addresses for a target sorted by the > TARGET_ADDRESS_PREFERABLE_P > hook above? Should we be asking the target to tell us which address type is > cheap? In any case, it seems to me that the cheapest address in a target is > something that only the target can tell, unless we agree on a universal > meaning and unit of measurement for address costs. > > What do people think? Would this approach be worth pursuing if the above > questions can be answered? From having a quick look at config/ I think that > converting the targets to use COSTS_N_INSNS units would not be a > controversial > task as long as the midend usage of address costs is consistent.
