[RFC]: Vectorization cost benefit changes.

All: I have done the vectorization cost changes as given below. I have considered only the cost associated with the inner instead of outside. The consideration of inside scalar and vector cost is done as the inner cost are the most cost effective than the outside cost. min_profitable_i

Re: Controlling instruction alternative selection

Thanks Jim, It took me a while to get back to this problem but as you suggested, exposing only the three address instructions prior to reload... in conjunction with implementing TARGET_CLASS_LIKELY_SPILLED_P has produced good results. After taking these measures I didn't have to disparage a

Re: Moving to git

On 20 August 2015 at 23:32, Jason Merrill wrote: > On 08/20/2015 04:33 PM, Joseph Myers wrote: >> * Make sure whatever process updates the github mirror is kept going after >> the conversion (actually it looks like it broke two weeks ago...). > > > I have no idea how this mirror is updated. Its gi

Re: Moving to git

On 08/20/2015 06:32 PM, Segher Boessenkool wrote: On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote: If we're going to migrate to git (I hope so), can we also please *slightly* revise the policy on commit messages, to add meaningful titles to commits? Currently: https://www.gnu.org/

Re: Moving to git

On 08/20/2015 04:33 PM, Joseph Myers wrote: On Thu, 20 Aug 2015, Jason Merrill wrote: It should be pretty straightforward to use the existing git mirror as the master repository; the main adjustment I'd want to make is rewriting the I think using the existing git mirror for this is a bad idea

Re: Moving to git

On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote: > If we're going to migrate to git (I hope so), can we also please > *slightly* revise the policy on commit messages, to add meaningful > titles to commits? > > Currently: > https://www.gnu.org/software/gcc/svnwrite.html#checkin says:

Re: Should we remove remnants of UWIN support in gcc/config.* files?

On August 20, 2015 5:22:47 PM EDT, Joseph Myers wrote: >On Thu, 20 Aug 2015, FX wrote: > >> > Well, they aren't *targets*, but *host* and *build* systems. >> >> Yes, but do we maintain a list of support host or build systems, that > >> would be different from our list of supported targets? > >I

Re: Should we remove remnants of UWIN support in gcc/config.* files?

On Thu, 20 Aug 2015, FX wrote: > > Well, they aren't *targets*, but *host* and *build* systems. > > Yes, but do we maintain a list of support host or build systems, that > would be different from our list of supported targets? I don't think there's such a list. For any such system that's not a

Re: Should we remove remnants of UWIN support in gcc/config.* files?

> Well, they aren't *targets*, but *host* and *build* systems. Yes, but do we maintain a list of support host or build systems, that would be different from our list of supported targets? (That’s a question out of curiosity. I do agree with the rest of your message: in practice, they are not sup

Re: Should we remove remnants of UWIN support in gcc/config.* files?

On Thu, 20 Aug 2015, FX wrote: > PS: gcc/config.host and gcc/config.build include some other such > targets… without checking them all, I think the following could be > removed: > > powerpc-*-beos > i370-*-opened* | i370-*-mvs* > i386-*-vsta > i[34567]86-*-udk* > i[34567]86-*-sysv4* > i[34567]8

Should we remove remnants of UWIN support in gcc/config.* files?

UWIN support was apparently removed from GCC in 2008. Yet some traces can still be found in gcc/config.* files. Attached patch would remove them. OK to commit? FX PS: gcc/config.host and gcc/config.build include some other such targets… without checking them all, I think the following could be

Re: Adding static-PIE support to binutils

On Thu, 20 Aug 2015, Rich Felker wrote: > On Wed, Aug 19, 2015 at 03:01:20PM +, Joseph Myers wrote: > > If a new option is added, of course it needs documenting in the ld manual > > (ld.texinfo). > > I can do that and resubmit the patch, but is there consensus that > adding a new option is a

Re: Adding static-PIE support to binutils

On Wed, Aug 19, 2015 at 03:01:20PM +, Joseph Myers wrote: > If a new option is added, of course it needs documenting in the ld manual > (ld.texinfo). I can do that and resubmit the patch, but is there consensus that adding a new option is appropriate? Like I said before I mildly lean that way

Re: Moving to git

> On Aug 20, 2015, at 4:24 PM, Jason Merrill wrote: > > On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote: >> Let's make sure the procedures that people are supposed to follow are >> clearly documented. I recently went looking for the equivalent in the >> binutils/gdb project and it doesn't

Re: Moving to git

On Thu, 20 Aug 2015, Jason Merrill wrote: > It should be pretty straightforward to use the existing git mirror as the > master repository; the main adjustment I'd want to make is rewriting the I think using the existing git mirror for this is a bad idea. To quote

Re: Moving to git

* Jeff Law: > I suspect Jakub will strongly want to see some kind commit hook to > associate something similar to an SVN id to each git commit to support > his workflow where the SVN ids are associated with the compiler > binaries he keeps around for very fast bisection. As long as we do not reb

Re: Moving to git

On 20 August 2015 at 19:23, Jeff Law wrote: > On 08/20/2015 11:57 AM, Jason Merrill wrote: >> >> I hear that at Cauldron people were generally supportive of switching >> over to git as the primary GCC repository, and talked about me being >> involved in that transition. Does anyone have more infor

Re: Moving to git

On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote: Let's make sure the procedures that people are supposed to follow are clearly documented. I recently went looking for the equivalent in the binutils/gdb project and it doesn't seem to be written down there, though if you ask enough questions

Re: Moving to git

> On Aug 20, 2015, at 4:09 PM, Jason Merrill wrote: > > On 08/20/2015 02:23 PM, Jeff Law wrote: >> ...As far as the trunk and release branches, are there any best practices >> out there that we can draw from? Obviously doing things like >> push-rebase-push is bad. Presumably there's others. >

Re: Moving to git

On 08/20/2015 03:31 PM, David Malcolm wrote: On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote: I hear that at Cauldron people were generally supportive of switching over to git as the primary GCC repository, and talked about me being involved in that transition. Does anyone have more info

Re: Moving to git

On 08/20/2015 02:23 PM, Jeff Law wrote: I suspect Jakub will strongly want to see some kind commit hook to associate something similar to an SVN id to each git commit to support his workflow where the SVN ids are associated with the compiler binaries he keeps around for very fast bisection. I t

Re: Moving to git

On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote: > I hear that at Cauldron people were generally supportive of switching > over to git as the primary GCC repository, and talked about me being > involved in that transition. Does anyone have more information about > this discussion? > > O

Re: Possible issue with using LAST_INSN_CODE

Jeff Law writes: > On 08/20/2015 11:28 AM, Claudiu Zissulescu wrote: >> Hi Jeff, >> >> In the gencodes.c:89, it explicitly decrements by one the return >> value of get_num_insn_codes(). While for the get_num_insn_codes is >> stated this: >> >> /* Return the number of possible INSN_CODEs. Only me

Re: Moving to git

On 08/20/2015 11:57 AM, Jason Merrill wrote: I hear that at Cauldron people were generally supportive of switching over to git as the primary GCC repository, and talked about me being involved in that transition. Does anyone have more information about this discussion? Our current workflow tran

Moving to git

I hear that at Cauldron people were generally supportive of switching over to git as the primary GCC repository, and talked about me being involved in that transition. Does anyone have more information about this discussion? Our current workflow translates over to a git master pretty easily:

Re: Possible issue with using LAST_INSN_CODE

On 08/20/2015 11:28 AM, Claudiu Zissulescu wrote: Hi Jeff, In the gencodes.c:89, it explicitly decrements by one the return value of get_num_insn_codes(). While for the get_num_insn_codes is stated this: /* Return the number of possible INSN_CODEs. Only meaningful once the whole file has

Re: Possible issue with using LAST_INSN_CODE

Hi Jeff, In the gencodes.c:89, it explicitly decrements by one the return value of get_num_insn_codes(). While for the get_num_insn_codes is stated this: /* Return the number of possible INSN_CODEs. Only meaningful once the whole file has been processed. */ I can provide an example for the

Re: Possible issue with using LAST_INSN_CODE

On 08/20/2015 02:54 AM, Claudiu Zissulescu wrote: Hi, The LAST_INSN_CODE is used to mark the last instruction code valid for a particular architecture (e.g., For ARM the value of LAST_INSN_CODE is 3799). Also this code (i.e., 3799) is used by a predicated instruction (e.g., for ARM this code is

Re: Question about "instruction merge" pass when optimizing for size

On 08/20/2015 01:07 AM, sa...@hederstierna.com wrote: From: Jeff Law More important is to determine *why* we're getting these patterns. In the IRA/LRA world, they should be a lot less common. Yes I agree this phenomena seems more common after introdu

Possible issue with using LAST_INSN_CODE

Hi, The LAST_INSN_CODE is used to mark the last instruction code valid for a particular architecture (e.g., For ARM the value of LAST_INSN_CODE is 3799). Also this code (i.e., 3799) is used by a predicated instruction (e.g., for ARM this code is used by predicated version of arm_usatsihi => {*p

Re: Using the asm suffix

David Wohlferd writes: > "gcc does not support using this feature with a non-static local variable > since typically such variables do not have assembler names." The technical term is "linkage", btw. An identifier with no linkage has no visible name in the assembler output. Andreas. -- Andre

Re: Question about "instruction merge" pass when optimizing for size

> > From: Jeff Law > More important is to determine *why* we're getting these patterns. In > the IRA/LRA world, they should be a lot less common. Yes I agree this phenomena seems more common after introducing LRA. Though I was thinking that such a pass