On 06/24/2015 09:46 PM, Jeff Law wrote:
> On 06/23/2015 07:00 PM, Sandra Loosemore wrote:
>> On 06/18/2015 11:32 AM, Eric Botcazou wrote:
>>>> The attached patch teaches regrename to validate insns affected by each
>>>> register renaming before making the change.  I can see at least two
>>>> other ways to handle this -- earlier, by rejecting renamings that
>>>> result
>>>> in invalid instructions when it's searching for the best renaming; or
>>>> later, by validating the entire set of renamings as a group instead of
>>>> incrementally for each one -- but doing it all in regname_do_replace
>>>> seems least disruptive and risky in terms of the existing code.
>>>
>>> OK, but the patch looks incomplete, rename_chains should be adjusted
>>> as well,
>>> i.e. regrename_do_replace should now return a boolean.
>>
>> Like this?  I tested this on nios2 and x86_64-linux-gnu, as before, plus
>> built for aarch64-linux-gnu and ran the gcc testsuite.
>>
>> The c6x back end also calls regrename_do_replace.  I am not set up to
>> build or test on that target, and Bernd told me off-list that it would
>> never fail on that target anyway so I have left that code alone.
>>
>> -Sandra
>>
>> regrename-2.log
>>
>>
>> 2015-06-23  Chung-Lin Tang<cltang@codesourcery.com>
>>         Sandra Loosemore<sandra@codesourcery.com>
>>
>>     gcc/
>>     * regrename.h (regrename_do_replace): Change to return bool.
>>     * regrename.c (rename_chains): Check return value of
>>     regname_do_replace.
>>     (regrename_do_replace): Re-validate the modified insns and
>>     return bool status.
>>     * config/aarch64/cortex-a57-fma-steering.c (rename_single_chain):
>>     Update to match rename_chains changes.
> As Eric mentioned, please put an assert to verify that the call from the
> c6x backend never fails.
>
> The regrename and ARM bits are fine.
>
> Do you have a testcase that you can add to the suite?  If so it'd be
> appreciated if you could include that too.
>
> Approved with the c6x assert if a testcase isn't available or
> exceedingly difficult to produce.

Thanks.  I've committed the attached version.

Re the testcase, this fixed 16 FAILs on existing tests in the gcc 
testsuite with the forthcoming nios2 load/store multiple instruction 
support, all assembler errors due to the bad instructions being 
generated.  There's nothing I can do on nios2 for a testcase until I get 
those patches committed (I'm still trying to re-test and tidy them up 
for submission), plus I think the failures are rather fragile -- 
depending on the register allocator choosing an initial register 
numbering that allows peephole optimizers to trigger, etc.  But, I will 
revisit this later and see what I can do.

-Sandra