[Bug target/93230] PowerPC GCC vec_extract of a vector in memory does not fold sign/zero extension into load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93230 --- Comment #7 from meissner at linux dot ibm.com --- On Sat, Jan 11, 2020 at 07:02:32AM +, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93230 > > --- Comment #4 from Andrew Pinski --- > Does it make sense to fold vec_extract directly into BIT_FIELD_REF in > altivec_resolve_overloaded_builtin for constants? > Or even in rs6000_fold_builtin ? > > It seems like a lot of the builtins should be fold directly to gimple > versions. Sure if somebody does the work. But note, vec_extract does support variable element numbers.
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #5 from meissner at linux dot ibm.com --- On Fri, Nov 09, 2018 at 02:28:28AM +, bergner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 > > --- Comment #3 from Peter Bergner --- > What do you think we can do about that? The call clobbers the ABI defined > non-volatile CR regs, so we have to save/restore them. I don't think we have > any other option, other than telling GCC to never use the non-volatile CR regs > so they never have to be saved/restored. Does using -ffixed-cr2 -ffixed-cr3 > -ffixed-cr4 help? I should clarify what I would like. Yes, if the compiler needs to preserve the CRs the current code works. But it would be helpful if instead of trying to preserve the CR across calls, that we re-do the initial comparison, instead of trying to keep the CR live for so long.
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 --- Comment #6 from meissner at linux dot ibm.com --- On Fri, Nov 09, 2018 at 02:47:31PM +, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 > > --- Comment #4 from Bill Schmidt --- > Seems like a potential opportunity for shrink-wrap separate on the CRs. I'm > not sure whether that's implemented yet. Not really, since shrink wrap only occurs if the program has an early exit condition. In this case, I don't think it is early exit, but instead the compiler is just lengthening the lifetime of the CR and moving it out of loops, etc.
