2014-10-10 21:35 GMT+04:00 Jeff Law <l...@redhat.com>: > On 10/10/14 11:33, Uros Bizjak wrote: >> >> On Fri, Oct 10, 2014 at 7:29 PM, Ilya Enkovich <enkovich....@gmail.com> >> wrote: >>> >>> 2014-10-10 21:10 GMT+04:00 Uros Bizjak <ubiz...@gmail.com>: >>>> >>>> On Wed, Oct 1, 2014 at 8:57 PM, Vladimir Makarov <vmaka...@redhat.com> >>>> wrote: >>>> >>>>> The problem is in code introduced by Bernd in IRA and caller-saves.c in >>>>> 2012. It is basically an optimization for functions returning always >>>>> the >>>>> same result as one argument (e.g. memcpy returning 1st argument). >>>>> >>>>> There are two possible solutions. First one is to prohibit the >>>>> optimizations when there is a parallel in SET. Second one is to go >>>>> deeper >>>>> if the call result is guaranteed in the first element which is true for >>>>> the >>>>> patch. >>>> >>>> >>>> I suspect that the first solution will regress >>>> gcc.target/i386/retarg.c on i686 - that testcase test if referred >>>> optimization is effective. All things equal, I think we should go with >>>> the second solution. >>> >>> >>> The first solutions is in trunk since October 3 >>> (https://gcc.gnu.org/ml/gcc-cvs/2014-10/msg00094.html) and I don't see >>> such fail. Patch actually just checks for a case which never occurs >>> right now and therefore should be quite safe. >> >> >> True, but after MPX patches are committed, PARALLELs will be passed as >> call targets. I wonder if the testcase fails then. > > Well, before those patches can be committed, they have to survive bootstrap > and regression testing as a whole :-)
Surely! Also PARALLEL will not be passed until you pass -mmpx flag. Ilya > > jeff
