RE: Turning off unrolling to certain loops
The basic idea is the same as what is described in this thread. http://gcc.gnu.org/ml/gcc/2008-05/msg00436.html But I made many changes on Alex's method. Pragmas are encoded into names of the helper functions because they are not optimized out by tree-level optimizer. These pseudo functions are either be consumed by target-builtins.c if it is only used at tree-level (unroll) or be replaced in target-builtins.c with special rtl NOTE(ivdep). To ensure the right scope of these loop pragmas, I also modified c_parser_for_statement, c_parser_while_statemennt, etc, to check loop level. I define that these pragmas only control the next innnermost loop. Once the right scope of the pragma is determined, I actually generate two helper functions for each pragma. The second is to close the scope of the pragma. When the pragma is used, I just search backward for preceding helper function (tree-level) or special note (rtl-level) Bingfeng > -Original Message- > From: fearyours...@gmail.com [mailto:fearyours...@gmail.com] > On Behalf Of Jean Christophe Beyler > Sent: 15 October 2009 17:27 > To: Bingfeng Mei > Cc: Zdenek Dvorak; gcc@gcc.gnu.org > Subject: Re: Turning off unrolling to certain loops > > I implemented it like this: > > - I modified c_parser_for_statement to include a pragma tree node in > the loop with the unrolling request as an argument > > - Then during my pass to handle unrolling, I parse the loop > to find the pragma. > - I retrieve the unrolling factor and use a merge of Zdenek's > code and yours to perform either a perfect unrolling or and register > it in the loop structure > > - During the following passes that handle loop unrolling, I > look at that variable in the loop structure to see if yes or no, we > should allow the normal execution of the unrolling > > - During the expand, I transform the pragma into a note that > will allow me to remove any unrolling at that point. > > That is what I did and it seems to work quite well. > > Of course, I have a few things I am currently considering: > - Is there really a position that is better for the pragma node in > the tree representation ? > - Can other passes actually move that node out of a given loop > before I register it in the loop ? > - Should I, instead of keeping that node through the tree > optimizations, actually remove it and later on add it just before > expansion ? > - Can an RTL pass remove notes or move them out of a loop ? > - Can the tree node or note change whether or not an optimization > takes place? > - It is important to note that after the registration, the pragma > node or note are actually just there to say "don't do anything", > therefore, the number of nodes or notes in the loop is not important > as long as they are not moved out. > > Those are my current concerns :-), I can give more > information if requested, > Jc > > PS: What exactly was your solution to this issue? > > > On Thu, Oct 15, 2009 at 12:11 PM, Bingfeng Mei > wrote: > > Jc, > > How did you implement #pragma unroll? I checked other > compilers. The > > pragma should govern the next immediate loop. It took me a while to > > find a not-so-elegant way to do that. I also implemented > #pragma ivdep. > > These information are supposed to be passed through both > tree and RTL > > levels and suvive all GCC optimization. I still have > problem in handling > > combination of unroll and ivdep. > > > > Bingfeng > > > >> -Original Message- > >> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com] > >> On Behalf Of Jean Christophe Beyler > >> Sent: 15 October 2009 16:34 > >> To: Zdenek Dvorak > >> Cc: Bingfeng Mei; gcc@gcc.gnu.org > >> Subject: Re: Turning off unrolling to certain loops > >> > >> You are entirely correct, I hadn't thought that through enough. > >> > >> So I backtracked and have just merged what Bingfeng Mei > has done with > >> your code and have now a corrected version of the loop unrolling. > >> > >> What I did was directly modified tree_unroll_loop to > handle the case > >> of a perfect unroll or not internally and then used > something similar > >> to what you had done around that. I added what I think is needed to > >> stop unrolling of those loops in later passes. > >> > >> I'll be starting my tests but I can port it to 4.5 if you are > >> interested to see what I did. > >> Jc > >> > >> On Thu, Oct 15, 2009 at 6:00 AM, Zdenek Dvorak > >> wrote: > >> > Hi, > >> > > >> >> I faced a similar issue a while ago. I filed a bug report > >> >> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712) In the end, > >> >> I implemented a simple tree-level unrolling pass in our port > >> >> which uses all the existing infrastructure. It works > quite well for > >> >> our purpose, but I hesitated to submit the patch because > >> it contains > >> >> our not-very-elegannt #prgama unroll implementation. > >> > > >> > could you please do so anyway? Even if ther
Is gcj dead?
Last news in http://gcc.gnu.org/java/ are dated March 2007. Also I submitted few PRs a month ago and there is no response at all. Yuri
Dealing with warnings on __attribute__((user)) when dehydra is not loaded
Given
void foo(void) __attribute__((user("bleh")));
GCC will complain
foo.cc:1: warning: 'user' attribute directive ignored
whenever dehydra is not loaded. Since our build system uses -Werror
for every build, users are not really able to use this attribute in
their dehydra scripts. Has anyone run into this? I have suggested
guarding the attribute with a special macro and define that macro
every time they use dehydra, but that's awkward.
We could change the compiler to never complain about the 'user'
attribute, unless plugins are loaded,but that also seems incomplete.
Compiling with -Wno-attributes helps, but that turns off all
attributes. Perhaps we could control warnings on the 'user' attribute
with a new -Wuser-attribute?
Thanks. Diego.
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
Diego Novillo wrote:
Given
void foo(void) __attribute__((user("bleh")));
GCC will complain
foo.cc:1: warning: 'user' attribute directive ignored
whenever dehydra is not loaded.
I am surprised & delighted that Diego mentions Dehydra. I thought it was
Taras Glek's plugin, so Mozilla (not Google) related. I even silently
dream that in a few years (or months) Diego would try melt.so - just an
innocent dream...
Diego, feel free to not answer to my curiosity if you don't want...
Since our build system uses -Werror
for every build, users are not really able to use this attribute in
their dehydra scripts. Has anyone run into this? I have suggested
guarding the attribute with a special macro and define that macro
every time they use dehydra, but that's awkward.
I thought that plugin can register attributes which are not even named
"user" but whose name is arbitrary. And I strongly believe it should be
so, because plugin foo.so could handle attribute "foogreen" & "fooblue"
& plugin bar.so could handle attribute "barbarian" [Sorry, I couldn't
resist that stupid joke].
We could change the compiler to never complain about the 'user'
attribute, unless plugins are loaded,but that also seems incomplete.
Compiling with -Wno-attributes helps, but that turns off all
attributes. Perhaps we could control warnings on the 'user' attribute
with a new -Wuser-attribute?
I have a simpler suggestion:
every attribute whose name starts with an underscore like "_user" or
"_foogreen" or "_BORING" never produce any warnings, except perhaps in
the plugin handling it.
Implementing such a convention would be simple. But it has to be
documented, not only in GCC internals, but also in GCC users, language
extension chapter.
Regards.
PS if the dev-static-analy...@lists.mozilla.org list is low volume, I
would like to subscribe if possible.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
On Fri, Oct 16, 2009 at 08:44, Basile STARYNKEVITCH wrote: > I am surprised & delighted that Diego mentions Dehydra. I thought it was > Taras Glek's plugin, so Mozilla (not Google) related. Dehydra still is developed by Mozilla. We are just starting to use it internally to implement some analyses. > I have a simpler suggestion: > > every attribute whose name starts with an underscore like "_user" or > "_foogreen" or "_BORING" never produce any warnings, except perhaps in the > plugin handling it. Yeah. Or perhaps a variant of this. Allow -Wno-attribute to take as argument the name of the attribute you want to ignore. > PS if the dev-static-analy...@lists.mozilla.org list is low volume, I would > like to subscribe if possible. I subscribed following some link from Dehydra's main page (https://developer.mozilla.org/en/Dehydra) Diego.
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
[ Posting again to gcc@ ]
On Fri, Oct 16, 2009 at 09:12, Benjamin Smedberg wrote:
> On 10/16/09 8:17 AM, Diego Novillo wrote:
>
>> void foo(void) __attribute__((user("bleh")));
>>
>> GCC will complain
>>
>> foo.cc:1: warning: 'user' attribute directive ignored
>>
>> whenever dehydra is not loaded. Since our build system uses -Werror
>> for every build, users are not really able to use this attribute in
>> their dehydra scripts. Has anyone run into this? I have suggested
>> guarding the attribute with a special macro and define that macro
>> every time they use dehydra, but that's awkward.
>
> That's what mozilla does. We have a --with-static-checking configure flag,
> and our annotations (NS_FINAL_CLASS etc) are defined conditionally. We have
> to do that anyway since we compile with MSVC and SunCC and other compilers.
OK.
> You could use -Wno-attributes, which suppresses warnings about *all* unknown
> attributes. Alternately, we could modify GCC so that -Wno-attributes takes
> an optional argument, e.g.
>
> -Wno-attributes=user
> -Wno-attributes=NS_stack
Good idea. I'll see about implementing this.
Thanks. Diego.
Ada Copyright Notice Nit
Hi, In checking my local changes, I noticed a minor difference in how the Ada source files have their Copyright notice. Some have a comma between the years and party, others do not. 9drpc.adb:-- Copyright (C) 1992-2009, Free Software Foundation, Inc. -- a-assert.adb:-- Copyright (C) 2007-2009 Free Software Foundation, Inc. -- Are both of these OK? Should they be changed to be the same? I doubt it makes any legal difference but we are normally picky on formatting in these areas. Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Turning off unrolling to certain loops
Wow, it seems more complicated then me. I think I will modify my approach to : - Add a node PRAGMA in the tree level when parsing the loop - As soon as the loop structures are in place, find the pragma, update the loop structure, remove the node - Before the loop structure is lost due to the transformation to RTL, create a note in the loop - As soon as the loop structures are valid again in RTL, find the notes and update the loop structures again, remove the notes For the moment, though I don't remove the nodes like I just said, I see no problems with this solutions, I've tried on multiple examples, single loops or nested loops, and it seems to be working fine. I will continue the testing, at worse, I'll change the notes to an RTL, my question is, how do you force it to not be taken out of the loop and how do you ensure it does not affect later pass optimizations ? I suppose you can remove them once you register their presence. Jc On Fri, Oct 16, 2009 at 5:09 AM, Bingfeng Mei wrote: > The basic idea is the same as what is described in this thread. > http://gcc.gnu.org/ml/gcc/2008-05/msg00436.html > But I made many changes on Alex's method. > > Pragmas are encoded into names of the helper functions because > they are not optimized out by tree-level optimizer. These > pseudo functions are either be consumed by target-builtins.c > if it is only used at tree-level (unroll) or be replaced in > target-builtins.c with special rtl NOTE(ivdep). > > To ensure the right scope of these loop pragmas, I also modified > c_parser_for_statement, c_parser_while_statemennt, etc, to check > loop level. I define that these pragmas only control the next > innnermost loop. Once the right scope of the pragma is determined, > I actually generate two helper functions for each pragma. The second > is to close the scope of the pragma. > > When the pragma is used, I just search backward for preceding > helper function (tree-level) or special note (rtl-level) > > > Bingfeng > >> -Original Message- >> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com] >> On Behalf Of Jean Christophe Beyler >> Sent: 15 October 2009 17:27 >> To: Bingfeng Mei >> Cc: Zdenek Dvorak; gcc@gcc.gnu.org >> Subject: Re: Turning off unrolling to certain loops >> >> I implemented it like this: >> >> - I modified c_parser_for_statement to include a pragma tree node in >> the loop with the unrolling request as an argument >> >> - Then during my pass to handle unrolling, I parse the loop >> to find the pragma. >> - I retrieve the unrolling factor and use a merge of Zdenek's >> code and yours to perform either a perfect unrolling or and register >> it in the loop structure >> >> - During the following passes that handle loop unrolling, I >> look at that variable in the loop structure to see if yes or no, we >> should allow the normal execution of the unrolling >> >> - During the expand, I transform the pragma into a note that >> will allow me to remove any unrolling at that point. >> >> That is what I did and it seems to work quite well. >> >> Of course, I have a few things I am currently considering: >> - Is there really a position that is better for the pragma node in >> the tree representation ? >> - Can other passes actually move that node out of a given loop >> before I register it in the loop ? >> - Should I, instead of keeping that node through the tree >> optimizations, actually remove it and later on add it just before >> expansion ? >> - Can an RTL pass remove notes or move them out of a loop ? >> - Can the tree node or note change whether or not an optimization >> takes place? >> - It is important to note that after the registration, the pragma >> node or note are actually just there to say "don't do anything", >> therefore, the number of nodes or notes in the loop is not important >> as long as they are not moved out. >> >> Those are my current concerns :-), I can give more >> information if requested, >> Jc >> >> PS: What exactly was your solution to this issue? >> >> >> On Thu, Oct 15, 2009 at 12:11 PM, Bingfeng Mei >> wrote: >> > Jc, >> > How did you implement #pragma unroll? I checked other >> compilers. The >> > pragma should govern the next immediate loop. It took me a while to >> > find a not-so-elegant way to do that. I also implemented >> #pragma ivdep. >> > These information are supposed to be passed through both >> tree and RTL >> > levels and suvive all GCC optimization. I still have >> problem in handling >> > combination of unroll and ivdep. >> > >> > Bingfeng >> > >> >> -Original Message- >> >> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com] >> >> On Behalf Of Jean Christophe Beyler >> >> Sent: 15 October 2009 16:34 >> >> To: Zdenek Dvorak >> >> Cc: Bingfeng Mei; gcc@gcc.gnu.org >> >> Subject: Re: Turning off unrolling to certain loops >> >> >> >> You are entirely correct, I hadn't thought that through enough. >> >> >> >> So I backtracked
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
Diego Novillo wrote:
On Fri, Oct 16, 2009 at 08:44, Basile STARYNKEVITCH
wrote:
I have a simpler suggestion:
every attribute whose name starts with an underscore like "_user" or
"_foogreen" or "_BORING" never produce any warnings, except perhaps in the
plugin handling it.
Yeah. Or perhaps a variant of this. Allow -Wno-attribute to take as
argument the name of the attribute you want to ignore.
I am not convinced that exactly is a very good idea. I would expect that
with plugins, we'll have significantly more attributes. I don't know if
having a really big CFLAGS (in Linux Makefile parlance) is a good idea.
The proposed underscore notation is quite simple, and suggest a notation
to separate the important attributes (those handled by GCC core) from
the other ones.
A more sophisticated variant would be to have every attribute belonging
to some attribute class, and have Wno-attributes=attributeclass but I
feel that is too complex!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Understanding IRA
Hi Vladimir, I have just begun working for Icera Inc, on a private port of GCC, and my first task has been to investigate the performance impact of using the Chaitin-Briggs algorithm of IRA vs the priority algorithm that we currently have enabled in our production compiler (due to not defining IRA_COVER_CLASSES). After running various tests, I measured little performance changes except for some test cases that have regressed quite considerably. My suspicion was that these regressions were due to our architecture having some instructions that can only use a subset of the register bank, so I set about trying to understand IRA enough to confirm this. I now believe I have now reached a point where I understand IRA enough to start thinking about how I can improve these regressed cases, but I thought it might be a good idea to formulate an email with my current understanding of IRA in it, so you could correct any errors before I continue. (I figure this exchange between us will also serve useful to other newbies in the field of GCC register allocation!) Without further ado, here is my current understanding of IRA (numbered for ease of reference). 1. You can enable full IRA, with Chaitin-Briggs coloring, by defining IRA_COVER_CLASSES, but you can just as easily disable it again by supplying -fira-algorithm=priority at the command line. (The latter is useful to know because it means you can compare two versions without recompiling.) 2. The priority algorithm allocates in an order determined by the allocno_priority_compare_func and calls into assign_hard_reg in that order to determine which allocno gets what register (or memory). 3. The CB algorithm puts allocnos into colored and uncolored buckets, according to conflicts between allocnos. The more conflicts, the more chance of being put in the uncolored bucket. Being in the uncolored bucket increases an allocno's chance of being spilled; being in the colored bucket guarantees that it will get a hard register. 4. When you run at -O0, the conflicts aspect of IRA is disabled (ira_conflict_p is set to false), and this subsequently causes the fast_allocation function to be used instead of the do_coloring IRA function. (This makes sense since you cannot separate into buckets without inspecting conflicts.) 5. Assuming ira_conflicts_p is enabled and you are using the CB algorithm, the two buckets are sorted using a bucket_allocno_compare_func, and this ordering is important, since it dictates the order each allocno will be pushed onto the stack and hence the order it will be popped from it (and assign_hard_reg called). 6. Allocnos from the colorable bucket always go on the stack first (in the order they were sorted) and then uncolorable ones, in an order based on which is the best candidate for spilling. Each time an allocno is added to the stack, conflicts may be reduced and there is the possibility of moving one or more allocnos from the uncolorable bucket to the colorable one (so they end up being added to the stack sooner than the other uncolorable ones). Near the end of processing the uncolorable bucket, there comes an opportunity to move all remaining allocnos to the colorable bucket (due to few remaining conflicts) and these get put on the stack last, and hence popped first, and so they all get registers. These final uncolorables will be those that had the highest spill cost and/or the most remaining conflicts. 7. The spill cost and priority calculation for determining which uncolorable to put on the stack first is important, for two main reasons: firstly, whichever allocno is picked is a more likely candidate for spilling; secondly, it will free other allocnos up to be added to the nicer colored bucket, from which an allocno always receives a hard register. If you could let me know if and where I've gone wrong with any of the above, I would be extremely grateful. Then, once we are on the same page, I hope you could also make some suggestions as to how I might help IRA work well with our instructions that can only use a subset of the register bank. Best regards, Ian Bolton (Compiler Engineer, Icera Inc.)
Re: Ada Copyright Notice Nit
Joel Sherrill writes: > In checking my local changes, I noticed a minor > difference in how the Ada source files have their > Copyright notice. Some have a comma between the > years and party, others do not. > > 9drpc.adb:-- Copyright (C) 1992-2009, Free Software > Foundation, Inc. -- > a-assert.adb:-- Copyright (C) 2007-2009 Free Software > Foundation, Inc. -- > > Are both of these OK? Should they be changed > to be the same? > > I doubt it makes any legal difference but we > are normally picky on formatting in these areas. We normally follow the GNU standard for copyright notices, which is here: http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html It says no comma. It also says do not use a dash between years, but instead list all the years individually. See the main gcc directory for a myriad examples. My understanding is that none of this makes any legal difference. I think it's more or less up to the Ada maintainers whether they want to strictly adhere to the GNU standards or not. Ian
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
Basile STARYNKEVITCH wrote:
A more sophisticated variant would be to have every attribute belonging
to some attribute class, and have Wno-attributes=attributeclass but I
feel that is too complex!
An even more crazy idea would be to interpret the argument to
-Wno-attribute as a regular expression (or file name globing pattern
like in the posix glob function, or prefix) for attributes to avoid.
And that suggestion would make Diego happy. He still would add
-Wno-attribute=user to ignore the __attribute__((user)) and I would use
-Wno-attribute='foo*' [if globbing] or -Wno-attribute='foo.*' [if using
regexps] or just Wno-attribute=foo [if prefixing] to mean don't output
attribute warning for any attribute whose name starts with foo.
However, I feel that is quite complex, and I would be happy with watever
people like.
In addition, one could think of a plugin specific argument to avoid
warning about its attributes, something like
-fplugin-arg-dehydra-dont-warn-attributes which would perhaps change (ie
add a flag or argument to) the callback registered thru PLUGIN_ATTRIBUTES
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Understanding IRA
Ian Bolton wrote: Hi Vladimir, I have just begun working for Icera Inc, on a private port of GCC, and my first task has been to investigate the performance impact of using the Chaitin-Briggs algorithm of IRA vs the priority algorithm that we currently have enabled in our production compiler (due to not defining IRA_COVER_CLASSES). After running various tests, I measured little performance changes except for some test cases that have regressed quite considerably. My suspicion was that these regressions were due to our architecture having some instructions that can only use a subset of the register bank, so I set about trying to understand IRA enough to confirm this. That is quite possible. Chaitin-Briggs algorithm has some problems when there are instructions using specific register subsets. It is well known and some researchers tried to solve the problem. The most known article about this is "A generalized algorithm for graph-coloring register allocation": http://130.203.133.121:8080/viewdoc/summary?doi=10.1.1.107.113 I am still working on this problem but I don't know when it will be finally in gcc. I now believe I have now reached a point where I understand IRA enough to start thinking about how I can improve these regressed cases, but I thought it might be a good idea to formulate an email with my current understanding of IRA in it, so you could correct any errors before I continue. (I figure this exchange between us will also serve useful to other newbies in the field of GCC register allocation!) The biggest problem of GCC RA is still reload pass. It frequently changes decisions of IRA not in a good way. Without further ado, here is my current understanding of IRA (numbered for ease of reference). 1. You can enable full IRA, with Chaitin-Briggs coloring, by defining IRA_COVER_CLASSES, but you can just as easily disable it again by supplying -fira-algorithm=priority at the command line. (The latter is useful to know because it means you can compare two versions without recompiling.) Correct. 2. The priority algorithm allocates in an order determined by the allocno_priority_compare_func and calls into assign_hard_reg in that order to determine which allocno gets what register (or memory). Correct. 3. The CB algorithm puts allocnos into colored and uncolored buckets, according to conflicts between allocnos. The more conflicts, the more chance of being put in the uncolored bucket. Being in the uncolored bucket increases an allocno's chance of being spilled; being in the colored bucket guarantees that it will get a hard register. I'd say if allocno goes to the coloring stack from the uncolored bucket, it will be probably spilled. Going to the coloring stack from coloring bucket means that the allocno most probably get a hard register. In theory it should be guaranteed but in practice it might not happen because of multi-registers allocnos, hard register conflicts with allocno, non-profitability of some hard registers (e.g. callee-saved vs callee-clobbered registers). Being in colored or uncolored bucket is defined by trivial colorability criteria which is classically based on conflicts left in the graph for given allocno. The criteria can be more complicated and exact but it might slow down RA a lot. 4. When you run at -O0, the conflicts aspect of IRA is disabled (ira_conflict_p is set to false), and this subsequently causes the fast_allocation function to be used instead of the do_coloring IRA function. (This makes sense since you cannot separate into buckets without inspecting conflicts.) Correct. Building conflicts is an expansive operation. Therefore -O0 (or fast) RA is based on live ranges. 5. Assuming ira_conflicts_p is enabled and you are using the CB algorithm, the two buckets are sorted using a bucket_allocno_compare_func, and this ordering is important, since it dictates the order each allocno will be pushed onto the stack and hence the order it will be popped from it (and assign_hard_reg called). Correct. But I should say it is only used for currently colored allocnos. You can not reorder two allocnos when putting the first allocno on the stack (in order words, removing trivially colored allocno from the graph) results in making the second allocno trivially colored. 6. Allocnos from the colorable bucket always go on the stack first (in the order they were sorted) and then uncolorable ones, in an order based on which is the best candidate for spilling. Each time an allocno is added to the stack, conflicts may be reduced and there is the possibility of moving one or more allocnos from the uncolorable bucket to the colorable one (so they end up being added to the stack sooner than the other uncolorable ones). Near the end of processing the uncolorable bucket, there comes an opportunity to move all remaining allocnos to the colorable bucket (due to few remaining conflicts) and these get put on the stack last, and hence popped first, and
Re: Understanding IRA
Ian Bolton wrote: I hope you could also make some suggestions as to how I might help IRA work well with our instructions that can only use a subset of the register bank. I forgot to write: thanks, it would be interesting for me to see your suggestions :)
Re: Ada Copyright Notice Nit
> > 9drpc.adb:-- Copyright (C) 1992-2009, Free Software > > Foundation, Inc. -- > > a-assert.adb:-- Copyright (C) 2007-2009 Free Software > > Foundation, Inc. -- > > > > Are both of these OK? Should they be changed > > to be the same? > > > > I doubt it makes any legal difference but we > > are normally picky on formatting in these areas. > > We normally follow the GNU standard for copyright notices, which is > here: > > http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html > > It says no comma. It also says do not use a dash between years, but > instead list all the years individually. See the main gcc directory > for a myriad examples. > > My understanding is that none of this makes any legal difference. I > think it's more or less up to the Ada maintainers whether they want to > strictly adhere to the GNU standards or not. The short answer is that we prefer the current state of things (use of dashes), and use of a comma after the date, so in the above, 9drpc.adb is "correct" and a-assert.adb isn't. Arno
Re: Understanding IRA
On 10/16/09 08:53, Vladimir Makarov wrote: The biggest problem of GCC RA is still reload pass. It frequently changes decisions of IRA not in a good way. Agreed. Not only may reload make a bad choice, it's horribly unpredictable. Trivial changes often lead to drastically different reloading decisions which in turn drastically change the final output. One of my favorites right now is the round-robin selection of spill registers to encourage reload inheritance. While I certainly understand the reasoning behind the code, it's amazingly frustrating to watch reload choose the worst possible spill register simply because of the round-robin selection. I've got a little hack in the reload-v2 branch which queries IRA to mitigate this problem, but it's merely a short-term hack until I can make reload inheritance go away. jeff
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
> "Diego" == Diego Novillo writes:
Diego> void foo(void) __attribute__((user("bleh")));
Diego> foo.cc:1: warning: 'user' attribute directive ignored
Diego> We could change the compiler to never complain about the 'user'
Diego> attribute, unless plugins are loaded,but that also seems incomplete.
How about just having __attribute__ ((plugin (pluginname, arg...)))
and ignoring an attribute when the named plugin is not loaded?
It seems to me that having a single "user" attribute shared by all
plugins will lead to some pain later on.
Tom
News Portal Crna-kronika.hr
Potovanje, u potpunosti je gotov portal www.crna-kronika.hr / www.crnakronika.com.hr , pa ukoliko vas interesira portal sa tematikom crne kronike OVO je pravo mjesto za vas. Ukoliko vas zanima marketing na naem portalu, kontaktirajte nas. S potovanjem, CRNA KRON!KA
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
On 10/16/09 12:11 PM, Tom Tromey wrote:
>> "Diego" == Diego Novillo writes:
>
> Diego> void foo(void) __attribute__((user("bleh")));
>
> Diego> foo.cc:1: warning: 'user' attribute directive ignored
>
> Diego> We could change the compiler to never complain about the 'user'
> Diego> attribute, unless plugins are loaded,but that also seems incomplete.
>
> How about just having __attribute__ ((plugin (pluginname, arg...)))
> and ignoring an attribute when the named plugin is not loaded?
> It seems to me that having a single "user" attribute shared by all
> plugins will lead to some pain later on.
Dehydra is going to switch from the generic user attribute to specific
GCC-registered attributes __attribute__((NS_final)) at some point when one
of us can code it up. In particular it would be nice to have more validation
of attribute application: in particular because the user attribute can apply
to types or declarations it's much easier for code authors to misplace,
especially when combined with function pointers.
I don't particularly like __attribute__((plugin (pluginname, arg))). You're
forced to code plugin names into your source, when you may not actually know
the name of the plugin that's going to process your annotations. Mozilla is
likely to have generic attributes (NS_final and others) which are not
specific to one plugin. We already have a volunteer working on an
optimization pass and an analysis pass for an attribute always_returns_zero:
these passes are likely to be in different plugins (optimization in a
compiled plugin, analysis in dehydra/treehydra).
--BDS
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
Tom Tromey wrote:
"Diego" == Diego Novillo writes:
Diego> void foo(void) __attribute__((user("bleh")));
Diego> foo.cc:1: warning: 'user' attribute directive ignored
Diego> We could change the compiler to never complain about the 'user'
Diego> attribute, unless plugins are loaded,but that also seems incomplete.
How about just having __attribute__ ((plugin (pluginname, arg...)))
and ignoring an attribute when the named plugin is not loaded?
It seems to me that having a single "user" attribute shared by all
plugins will lead to some pain later on.
I don't agree necessarily on the syntax, but I strongly agree that
plugins should have their own attribute name, a single "user" attribute
is impractical to share between plugins.
Plugins dhould be able to register their attribute names.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Dealing with warnings on __attribute__((user)) when dehydra is not loaded
> "Benjamin" == Benjamin Smedberg writes: Benjamin> Dehydra is going to switch from the generic user attribute to Benjamin> specific GCC-registered attributes __attribute__((NS_final)) Benjamin> at some point when one of us can code it up. Benjamin> I don't particularly like __attribute__((plugin (pluginname, Benjamin> arg))). You're forced to code plugin names into your source, Benjamin> when you may not actually know the name of the plugin that's Benjamin> going to process your annotations. Yeah, that makes sense. It seems to me that there are two problems here. One is the namespace problem, and the other is avoiding warnings for certain attributes. Registering attributes by name solves the first one but not the second. Tom
Alias analysis or DSE problem?
I'm currently porting a plug-in that used to target the 4.3.0-based plug-in branch to the new top-of-tree plug-in system. I'm really stymied by a bug whose source I just cannot track down! Usually that means there is an error in my code, but the problem seems to involve tree-ssa-dse.c and tree-ssa-alias.c, so I wanted to ask for a bit of help from the list. The plug-in is relatively simple: it's designed to synthesize calls to a hook function in specific places. I streamlined the plug-in to the simplest case that still triggers the bug: the function call has just one argument, which is a pointer to a string constant. The test program I'm instrumenting gets hook calls in two places. The first one goes in without a problem (I can compile the program and verify that the hook gets called with the correct string), but the second (basically identical) call triggers an assertion failure during the Dead Store Elimination (dse) pass. The problem occurs in dse_possible_dead_store_p() getting called for a GIMPLE_ASSIGN that comes just before the inserted GIMPLE_CALL in the same basic block. dse_possible_dead_store_p() pulls the gimple_vdef out of this GIMPLE_ASSIGN (which is an SSA_NAME reference to .MEM) and then iterates through its imm_uses list (with FOR_EACH_IMM_USE_STMT). The surpise to me is that my inserted GIMPLE_CALL hook is somehow in that list! That results in dse_possible_dead_store_p() checking the hook call with ref_maybe_used_by_call_p(), which goes through each argument in the call (in this case just a pointer to a string constant) to check if it aliases with another variable with refs_may_alias_p_1(). The reference is an ADDR_EXPR, though, which it appears does not ever belong in refs_may_alias_p_1(). I say that because of the assertion statement at the because of refs_may_alias_p_1(): gcc_assert ((!ref1->ref || SSA_VAR_P (ref1->ref) || handled_component_p (ref1->ref) || INDIRECT_REF_P (ref1->ref) || TREE_CODE (ref1->ref) == TARGET_MEM_REF)... My ADDR_EXPR does not meet any of those conditions, so something has gone wrong here! After figuring all that out, I'm stuck with a ton of questions: 1) Why is my inserted GIMPLE_CALL hook ending up in some SSA_NAME's imm_uses list? The correctly working hook never gets inserted onto an imm_uses list, so what could be making this one different? Is it possible that I malformed the GIMPLE_CALL in some way that would cause that? 2) Why is the assertion at the beginning of may_alias_p_1() there? Somebody is responsible for making sure that refs who don't pass this check never end up in may_alias_p_1(), but who? Should ref_maybe_used_by_call_p() actually be making this check before calling may_alias_p_1(), or should I be forming GIMPLE_CALLs so that all their arguments are suitable for may_alias_p_1()? Sorry for this enormous brain-dump e-mail! I'm still really new to GCC, and I'd appreciate any guidance I can get here. Thanks. --Justin
Constraint modifier for partially overlaping operands
Hi I can use "=" modifier to make operands use same register and early clobber "&" to avoid overlaps. Is it possible to have or construct a contraint that permits partial overlap operands. (which neither = or & would allow) The case would be wide types taking multiple hard registers. eg Input r20..23 Output r22..25 Andy
Re: Constraint modifier for partially overlaping operands
Andrew Hutchinson writes: > I can use "=" modifier to make operands use same register and early > clobber "&" to avoid overlaps. > > Is it possible to have or construct a contraint that permits partial > overlap operands. (which neither = or & would allow) > The case would be wide types taking multiple hard registers. > > eg Input r20..23 Output r22..25 There is no such constraint today. I suppose it would be possible to define such a constraint if it seemed useful. It would not be a simple change. A number of different parts of the compiler know about register constraints, and some of them would have to change in relatively substantial ways to track this. Ian
