Re: Help with getting started with adding IPA-related attribute
1.) decides rather or not to inline a function, 2.) decides rather or not to make a .constprop version of a function, 3.) a good pass (when all constant propagation is done) to search for fn parameters and variables (marked with an attribute) that were not constproped away, and finally 4.) what mechanism should I use for that search? (iterate through the tree to find them and then see if they have rtl? I haven't worked in this area yet. I've got 3 & 4 worked out as well as most of 1 & 2. I'm learning the CFG which is quite complex and fascinating. It would appear that it is already performing some of the constant propagation that I wanted it to do (without the new attribute), and yet many constancy tests fail unless the function is "always_inline"ed from the caller "flatten". I'll have to dig more to figure out why. Daniel
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On Sat, 29 Apr 2017, Segher Boessenkool wrote: > We also still have to agree on the target triples for the new port. > If you have any thoughts on this, I'd love to hear them. It seems fairly obvious that the powerpc-*-eabispe* and powerpc*-*-linux*spe* triples should continue to work while being mapped to the new CPU port. It's less obvious what triples should be used for SPE versions of other SPE-supporting configurations such as powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*. Some testcases will be applicable to both ports, some to only one. Maintainers of each port should of course watch the other port for changes that should be carried across, even if we believe, as has been stated in this discussion, that the parts of the code that would be present in both ports are stable and very rarely change. -- Joseph S. Myers jos...@codesourcery.com
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On Mon, May 01, 2017 at 10:48:05AM +, Joseph Myers wrote: > On Sat, 29 Apr 2017, Segher Boessenkool wrote: > > > We also still have to agree on the target triples for the new port. > > If you have any thoughts on this, I'd love to hear them. > > It seems fairly obvious that the powerpc-*-eabispe* and > powerpc*-*-linux*spe* triples should continue to work while being mapped > to the new CPU port. It's less obvious what triples should be used for > SPE versions of other SPE-supporting configurations such as > powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*. My current patches have powerpc*-*-*spe* for the powerpcspe port. Maybe it should also allow powerpcspe-*-*? If people are willing to change the target triple they use. > Some testcases will be applicable to both ports, some to only one. Yeah; but we can sort that out later, no change is needed as long as the new port is essentially a copy of rs6000 :-) > Maintainers of each port should of course watch the other port for changes > that should be carried across, even if we believe, as has been stated in > this discussion, that the parts of the code that would be present in both > ports are stable and very rarely change. Right. Segher
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On Mon, 1 May 2017, Segher Boessenkool wrote: > My current patches have powerpc*-*-*spe* for the powerpcspe port. > Maybe it should also allow powerpcspe-*-*? If people are willing > to change the target triple they use. In that case, either config.sub or config.gcc could handle the mapping. > > Some testcases will be applicable to both ports, some to only one. > > Yeah; but we can sort that out later, no change is needed as long as > the new port is essentially a copy of rs6000 :-) Presumably the SPE port maintainers will want to clean up the SPE port soon so it's not simply a copy of rs6000 (removing all the options, ABI variants etc. not applicable to SPE-supporting processors). -- Joseph S. Myers jos...@codesourcery.com
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On Mon, May 01, 2017 at 11:30:59AM +, Joseph Myers wrote: > On Mon, 1 May 2017, Segher Boessenkool wrote: > > > My current patches have powerpc*-*-*spe* for the powerpcspe port. > > Maybe it should also allow powerpcspe-*-*? If people are willing > > to change the target triple they use. > > In that case, either config.sub or config.gcc could handle the mapping. For powerpc*-*-*spe* in config.gcc, for powerpcspe-*-* in config.sub, yes. Which is also why the latter is a larger change: all other packages would see it as a separate arch, too; which might make it a non-starter. > > > Some testcases will be applicable to both ports, some to only one. > > > > Yeah; but we can sort that out later, no change is needed as long as > > the new port is essentially a copy of rs6000 :-) > > Presumably the SPE port maintainers will want to clean up the SPE port > soon so it's not simply a copy of rs6000 (removing all the options, ABI > variants etc. not applicable to SPE-supporting processors). Yes, and vice-versa. Of course the powerpcspe port can remove a lot more (VMX, VSX, 64-bit!) But these are the easy parts :-) Segher
gcc-prs mailing list?
Hi, is the gcc-prs mailing list active? The archives show no bugs entered for example for https://gcc.gnu.org/ml/gcc-prs/2017-04/ . Regards Thomas
Re: gcc-prs mailing list?
On Mai 01 2017, Thomas Koenig wrote: > is the gcc-prs mailing list active? Not any more since GCC has started using bugzilla back in 2003. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On 5/1/2017 5:48 AM, Joseph Myers wrote: On Sat, 29 Apr 2017, Segher Boessenkool wrote: We also still have to agree on the target triples for the new port. If you have any thoughts on this, I'd love to hear them. It seems fairly obvious that the powerpc-*-eabispe* and powerpc*-*-linux*spe* triples should continue to work while being mapped to the new CPU port. It's less obvious what triples should be used for SPE versions of other SPE-supporting configurations such as powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*. powerpc-*-rtemsspe* would be OK. powerpc-*-eabisimspe* is pretty ugly though. It is obvious but if powerpc-*-XXXspe* is the pattern, then the spe cases need to be above in all configure switches. I hate to mention it but a fair number of odd RTEMS issues turn out to be from inadvertent side-effects when cleaning up configure switches. Some testcases will be applicable to both ports, some to only one. Maintainers of each port should of course watch the other port for changes that should be carried across, even if we believe, as has been stated in this discussion, that the parts of the code that would be present in both ports are stable and very rarely change. --joel
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On 5/1/2017 10:47 AM, Joel Sherrill wrote: On 5/1/2017 5:48 AM, Joseph Myers wrote: On Sat, 29 Apr 2017, Segher Boessenkool wrote: We also still have to agree on the target triples for the new port. If you have any thoughts on this, I'd love to hear them. It seems fairly obvious that the powerpc-*-eabispe* and powerpc*-*-linux*spe* triples should continue to work while being mapped to the new CPU port. It's less obvious what triples should be used for SPE versions of other SPE-supporting configurations such as powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*. powerpc-*-rtemsspe* would be OK. powerpc-*-eabisimspe* is pretty ugly though. After I sent this, I saw in another response that powerpcspe*-*-* was proposed. Is that clearer? For rtems, we already used versioned triplets. powerpc-rtems4.12 for example. owerpcspe-rtems4.12 seems more correct because spe is part of the CPU architecture. Otherwise, would it be powerpc-rtems4.12spe or powerpc-rtemsspe4.12. Both of those are pretty ugly and confuse the third part. It is obvious but if powerpc-*-XXXspe* is the pattern, then the spe cases need to be above in all configure switches. I hate to mention it but a fair number of odd RTEMS issues turn out to be from inadvertent side-effects when cleaning up configure switches. Some testcases will be applicable to both ports, some to only one. Maintainers of each port should of course watch the other port for changes that should be carried across, even if we believe, as has been stated in this discussion, that the parts of the code that would be present in both ports are stable and very rarely change. --joel --joel
Re: [C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)
OK.
On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini wrote:
> Hi again,
>
> On 26/04/2017 12:32, Paolo Carlini wrote:
>>
>> Hi,
>>
>> in 2013 (2013-09-16) Adam added two slightly obscure functions and I can't
>> find much around in terms of rationale, etc:
>>
>> /* Returns true iff TYPE is a TEMPLATE_TYPE_PARM representing 'auto',
>>'decltype(auto)' or a concept. */
>>
>> bool
>> is_auto_or_concept (const_tree type)
>> {
>> return is_auto (type); // or concept
>> }
>>
>> /* Returns the TEMPLATE_TYPE_PARM in TYPE representing a generic type
>> (`auto' or
>>a concept identifier) iff TYPE contains a use of a generic type.
>> Returns
>>NULL_TREE otherwise. */
>>
>> tree
>> type_uses_auto_or_concept (tree type)
>> {
>> return find_type_usage (type, is_auto_or_concept);
>> }
>>
>> The latter seems completely unused (it's meant for debugging purposes?);
>> the former evidently simply forwards to is_auto, and we end up in the
>> front-end with uses of both, which in fact are equivalent, which seems
>> weird: IMHO, if they are actually equivalent in our implementation we should
>> clearly explain that in the comment and have only one. Or what?
>
>
> ... replying to myself, in practice we could do the below, which certainly
> passes testing, and in fact now seems to me even more obvious than I thought
> a couple of days ago...
>
> Thanks,
> Paolo.
>
> /
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On Mon, May 01, 2017 at 10:55:53AM -0500, Joel Sherrill wrote: > >powerpc-*-rtemsspe* would be OK. > > > >powerpc-*-eabisimspe* is pretty ugly though. > > > After I sent this, I saw in another response that powerpcspe*-*-* > was proposed. Is that clearer? Yes, it does not have part of the architecture name in the OS field ;-) We can support both: we need to support powerpc*-*-*spe* because that is what people use today, but we can support powerpcspe-*-* as well. > For rtems, we already used versioned triplets. powerpc-rtems4.12 > for example. owerpcspe-rtems4.12 seems more correct because spe > is part of the CPU architecture. > > Otherwise, would it be powerpc-rtems4.12spe or powerpc-rtemsspe4.12. > Both of those are pretty ugly and confuse the third part. I agree. People wanting to match either can use powerpc*-x-x (which they likely already have because of powerpc64, powerpc64le, powerpcle!) So if you need to define a new target triple anyway, powerpcspe-*-* is probably the way to go. Segher
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
FWIW, at AdaCore we're using e500v2-wrs-vxworks for our VxWorks toolchain for SPE. Arno
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
On Mon, May 01, 2017 at 06:12:37PM +0200, Arnaud Charlet wrote: > FWIW, at AdaCore we're using e500v2-wrs-vxworks for our VxWorks > toolchain for SPE. config.sub translates that to powerpc-wrs-vxworksspe so that works. Segher
