Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register

[Renlin Li <renlin.li@foss.arm.com>]

Hi Ramana,

On 11/06/2018 10:57 AM, Ramana Radhakrishnan wrote:
> On Tue, Nov 6, 2018 at 10:52 AM Renlin Li <renlin.li@foss.arm.com> wrote:
>>
>> Hi Jeff & Peter,
>>
>> On 11/05/2018 07:41 PM, Jeff Law wrote:
>>> On 11/5/18 12:36 PM, Peter Bergner wrote:
>>>> On 11/5/18 1:20 PM, Jeff Law wrote:
>>>>> On 11/1/18 4:07 PM, Peter Bergner wrote:
>>>>>> On 11/1/18 1:50 PM, Renlin Li wrote:
>>>>>>> Is there any update on this issues?
>>>>>>> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
>>>>>>
>>>>>>   From the analysis I've done, my commit is just exposing latent issues
>>>>>> in LRA.  Can you try the patch I submitted here to see if it helps?
>>>>>>
>>>>>>     https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01757.html
>>>>>>
>>>>>> It survives on powerpc64le-linux, x86_64-linux and s390x-linux.
>>>>>> Jeff threw it on his testers and said he saw an arm issue and was
>>>>>> trying to come up with a test case for me to debug.
>>>>> So I don't think the ARM issues are related to your patch, they may have
>>>>> been related the combiner changes that went in around the same time.
>> Yes, there are issues related to the combiner changes.
> 
> But didn't the combiner changes come *after* these patches ? So IIUC,
> Renlin has been trying to get these fixed *without* the combine
> patches but just with your patch applied on top of the revision where
> the problem started showing up .
> 
> Can you confirm that Renlin ?

I just did a bootstrap again with everything up to r264897 which is Oct 6.
it produce the ICE I mentioned on the PR87899.

The first combiner patch on Oct 22.

Regards,
Renlin

> 
> 
> Ramana
>>
>> But the IRA/LRA change dose cause the arm-none-linux-gnueabihf bootstrap native toolchain mis-compiled.
>> And the new patch seems not fix this problem.
>>
>> I am trying to extract a test case, but it is a little bit hard as the toolchain itself is mis-compiled.
>> And it ICEs when compile test case with it.
>>
>> I created a bugzilla ticket for this, PR87899.
>>
>> ./gcc/cc1 ~/gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c  -O3
>>    test main
>> Analyzing compilation unit
>> Performing interprocedural optimizations
>>    <*free_lang_data> <visibility> <build_ssa_passes> <opt_local_passes> <targetclone> <free-fnsummary> <increase_alignment>Streaming LTO
>>    <whole-program> <profile_estimate> <icf> <devirt> <cp> <fnsummary> <inline> <pure-const> <free-fnsummary> <static-var> <single-use>
>> <comdats>Assembling functions:
>>    <materialize-all-clones> testduring GIMPLE pass: ldist
>>
>> gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c: In function ‘test’:
>> gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c:9:1: internal compiler error: Segmentation fault
>>       9 | test (void)
>>         | ^~~~
>> 0x5c3a37 crash_signal
>>          ../../gcc/gcc/toplev.c:325
>> 0x63ef6b inchash::hash::add(void const*, unsigned int)
>>          ../../gcc/gcc/inchash.h:100
>> 0x63ef6b inchash::hash::add_ptr(void const*)
>>          ../../gcc/gcc/inchash.h:94
>> 0x63ef6b ddr_hasher::hash(data_dependence_relation const*)
>>          ../../gcc/gcc/tree-loop-distribution.c:143
>> 0x63ef6b hash_table<ddr_hasher, xcallocator>::find_slot(data_dependence_relation* const&, insert_option)
>>          ../../gcc/gcc/hash-table.h:414
>> 0x63ef6b get_data_dependence
>>          ../../gcc/gcc/tree-loop-distribution.c:1184
>> 0x63f2bd data_dep_in_cycle_p
>>          ../../gcc/gcc/tree-loop-distribution.c:1210
>> 0x63f2bd update_type_for_merge
>>          ../../gcc/gcc/tree-loop-distribution.c:1255
>> 0x64064b build_rdg_partition_for_vertex
>>          ../../gcc/gcc/tree-loop-distribution.c:1302
>> 0x64064b rdg_build_partitions
>>          ../../gcc/gcc/tree-loop-distribution.c:1754
>> 0x64064b distribute_loop
>>          ../../gcc/gcc/tree-loop-distribution.c:2795
>> 0x642299 execute
>>          ../../gcc/gcc/tree-loop-distribution.c:3133
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See <https://gcc.gnu.org/bugs/> for instructions.
>>
>>
>>
>> Regards
>> Renlin
>>
>>
>>
>>>>>
>>>>> At this point your patch appears to be DTRT across the board.  The only
>>>>> fallout is the bogus s390 asm it caught in the kernel.
>>>>
>>>> Cool.  I will note that I contacted the s390 kernel guys and gave them a
>>>> fix to their broken constraints in that asm and they are going to fix it.
>>> Sounds good.  I've got a hack in my tester to "fix" that bogus asm until
>>> the kernel folks do it right.
>>>
>>>
>>>>
>>>> Is the above an approval to commit the patch mentioned above or do you
>>>> still want to wait until the ARM issues are fully resolved?
>>> I think knowing the patch addresses all the known issues related to the
>>> earlier IRA/LRA change unblocks the review step.  I don't think we need
>>> to wait for the other ARM issues to be resolved -- they seem to be
>>> unrelated to the IRA/LRA changes.
>>>
>>> jeff
>>>