On Mon, Jun 30, 2014 at 5:42 PM, Jeff Law <l...@redhat.com> wrote:
> On 06/26/14 14:13, Jeff Law wrote:
>>
>> On 06/26/14 02:44, Bin.Cheng wrote:
>>>
>>> Hi,
>>> I ran into PR60947, in which GCC understands the return value of
>>> memset is the first argument passed in, according to standard, then
>>> does optimization like below:
>>> mov ip, sp
>>> stmfd sp!, {r4, r5, r6, r7, r8, r9, r10, fp, ip, lr, pc}
>>> sub fp, ip, #4
>>> sub sp, sp, #20
>>> ldr r8, [r0, #112]
>>> add r3, r8, #232
>>> add r4, r8, #328
>>> .L1064:
>>> mov r0, r3
>>> mov r1, #255
>>> mov r2, #8
>>> bl memset
>>> add r3, r0, #32 <----X
>>> cmp r3, r4
>>> bne .L1064
>>>
>>> For X insn, GCC takes advantage of standard by using the returned r0
>>> directly.
>>>
>>> My question is, is it always safe for GCC to do such optimization? Do
>>> we have an option to disable such standard dependent optimization?
>>
>> Others have already answered this question.
>>
>> FWIW, I just locally added the capability to track equivalences between
>> the destination argument to the various mem* str* functions and their
>> return value in DOM. It triggers, but not terribly often. I'll be
>> looking to see if the additional equivalences actually enable any
>> optimizations before going through the full bootstrap and test.
>
> Just as a follow-up. This turns out to be a relatively bad idea as it gets
> in the way of tail call optimizations.
>
> Probably the only place where this is going to really be useful is in the
> allocators to allow us to cheaply rematerialize values and/or tie together
> two values that normally wouldn't be seen as related to each other.
Also it restrict the inline of string operation functions at expand
time. Once we reuse the return value then inlining need to calculate
the return value. I don't know if it will break some targets
expand/inline now, but it surely increases cost of inlined code.
Thanks,
bin
>
> Jeff
>
