This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR63404, gcc 5 miscompiles linux block layer
- From: Jiong Wang <wong dot kwongyuan dot tools at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Jiong Wang <jiong dot wang at arm dot com>, Richard Henderson <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 30 Sep 2014 19:36:54 +0100
- Subject: Re: [PATCH] PR63404, gcc 5 miscompiles linux block layer
- Authentication-results: sourceware.org; auth=none
- References: <5429A102 dot 4000602 at arm dot com> <5429A5D9 dot 9040404 at redhat dot com> <5429B204 dot 7040200 at arm dot com> <542A2FC5 dot 4020605 at redhat dot com> <542AC02D dot 70508 at arm dot com> <542ADA9D dot 8070709 at redhat dot com>
2014-09-30 17:30 GMT+01:00 Jeff Law <law@redhat.com>:
> On 09/30/14 08:37, Jiong Wang wrote:
>>
>>
>> On 30/09/14 05:21, Jeff Law wrote:
>>>
>>> On 09/29/14 13:24, Jiong Wang wrote:
>>>>
>>>> I don't think so. from the x86-64 bootstrap, there is no regression
>>>> on the number of functions shrink-wrapped. actually speaking,
>>>> previously only single mov dest, src handled, so the disallowing
>>>> USE/CLOBBER will not disallow shrink-wrap opportunity which was
>>>> allowed previously.
>>>
>>> This is the key, of course. shrink-wrapping is very restrictive in its
>>> ability to sink insns. The only forms it'll currently shrink are simple
>>> moves. Arithmetic, logicals, etc are left alone. Thus disallowing
>>> USE/CLOBBER does not impact the x86 port in any significant way.
>>
>>
>> yes, and we could get +1.22% (2567 compared with 2536) functions
>> shrink-wrapped
>> after we sinking more insn except simple "mov dest, src" on x86-64
>> bootstrap. and
>> I remember the similar percentage on glibc build.
>>
>> while on aarch64, the overall functions shrink-wrapped increased +25% on
>> some
>> programs. maybe we could gain the same on other RISC backend.
>>
>>>
>>> I do agree with Richard that it would be useful to see the insns that
>>> are incorrectly sunk and the surrounding context.
>
> So I must be missing something. I thought the shrink-wrapping code wouldn't
> sink arithmetic/logical insns like we see with insn 14 and insn 182. I
> thought it was limited to reg-reg copies and constant initializations.
yes, it was limited to reg-reg copies, and my previous sink improvement aimed to
sink any rtx
A: be single_set
B: the src operand be any combination of no more than one register
and no non-constant objects.
while some operator like shift may have side effect. IMHO, all side
effects are reflected on RTX,
together with this fail_on_clobber_use modification, the rtx returned
by single_set_no_clobber_use is
safe to sink if it meets the above limit B and pass later register
use/def check in move_insn_for_shrink_wrap ?
Regards,
Jiong
>
> Jeff
>
>