On Fri, Jun 27, 2014 at 4:13 AM, Jeff Law <l...@redhat.com> 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.
>
> It doesn't help your testcase though since optimizer weakness you're showing
> is much later in the optimization pipeline. I wonder if you could model
> this as an implicit copy in IRA and try to encourage IRA to tie the hard reg
> output from memset to the pseudo.
Thanks for pointing me the direction. I shall have a look at it.
Thanks,
bin
>
>
> jeff
>
>
