[PATCH] PR63404, gcc 5 miscompiles linux block layer
Tue Sep 30 18:37:00 GMT 2014
2014-09-30 17:30 GMT+01:00 Jeff Law <email@example.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
>> 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
>> 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 ?
More information about the Gcc-patches