This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, rs6000] Switch the rs6000 port over to LRA


On Wed, Aug 3, 2016 at 6:59 PM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> On 8/2/16 3:17 PM, Peter Bergner wrote:
>>
>> Now that Vlad has fixed PR69847, which was the last problem holding the
>> rs6000 port from switching from reload to LRA, we are ready to flip the
>> switch.
>>
>> Is the following ok once bootstrap/regtesting on both LE and BE
>> (32 & 64 regtesting) comes out clean?
>
>
> So we have two "regressions":
>
> +FAIL: gcc.target/powerpc/bool3-p7.c scan-assembler-not [ \\t]xxlnor
> +FAIL: gcc.target/powerpc/bool3-p8.c scan-assembler-not [ \\t]xxlnor
>
>
> Looking into these "failures", they show up because when we enable
> LRA, we also implicitly enable -mvsx-timode and these failures are
> due to -mvsx-timode.  The same test cases fail when we use -mvsx-timode
> with reload.
>
> I'll note that these failures are not code correctness bugs, but
> performance bugs.  I plan to open a bugzilla to track the fixing
> of these failures.
>
> My question, is since these failures are not due to LRA, do we
> want to consider the switch to LRA ok to commit or do we want to
> wait until the -mvsx-timode performance bug is fixed?

Peter,

Please go ahead and commit the LRA switch patch.

Please open a Bugzilla for the rs6000 backend about the vsx-timode
performance regression.  The vsx-timode regression needs to be fixed
for GCC 7.

Thanks, David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]