----- Original Message ----- > From: "Joerg Sonnenberger" <[email protected]> > To: [email protected] > Sent: Thursday, January 15, 2015 6:22:31 AM > Subject: Re: r225958 - Use the integrated assembler by default on 32-bit > PowerPC and SPARC. > > On Wed, Jan 14, 2015 at 07:08:58PM -0800, Chandler Carruth wrote: > > FWIW, I still don't think it's reasonable to change strategy like > > this just > > before cutting a release. I think that 3.6 shouldn't have this > > change so > > that we can prepare for it in the run up to 3.7. > > I don't agree on this. The central point is that using IAS actually > creates *less* problems.
>From whom does it create fewer problems? For you? This is not necessarily the >only relevant concern. While you and others have contributed a lot to the PPC assembler, and have been the primary testers on PPC32, and those contributions are greatly appreciated, this is still a major change with the potential to break a lot of peoples' builds. Please remember that while only recently has PPC32 has PIC/TLS support for non-Darwin systems, the LLVM PPC backend for PPC32 has worked just fine for static compiles, and people have been using it for that. And, FWIW, I still receive bug reports for missing instructions on PPC not rarely (I just added some more yesterday). That having been said, I'm comfortable with the fact that the integrated assembler for PPC32 is likely of comparable quality to that for PPC64, so I don't object to making the change. Making the change the day before we branch for a release is questionable, and I'd prefer it be enabled in trunk for some time first, but given the history, I don't object strongly to the change going into 3.6. I find the change for SPARC more problematic. How much testing has been done? Was the target's code owner involved? Brad said, "The SPARC backend is still quite experimental and has rough edges." seemly trying to justify making the change without wide consultation first. This is problematic. The SPARC backend has been around for a long time, and while not production quality in a holistic sense, still has a number of users in both academia and industry (I'm continually surprised how many people mention it to me at the dev meetings). Just because it has rough edges does not justify adding more without discussion on the dev list. -Hal > > Joerg > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
