This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about GCC's standard dependent optimization

On Thu, Jun 26, 2014 at 10:13 PM, 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.
> 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.

Btw, we have the "fn spec" attribute and gimple_call_return_flags ()
which can return ERF_RETURNS_ARG and you can query which
one by masking with ERF_RETURN_ARG_MASK.  That's how
calls.c figures this out.  Note we miss to annotate builtins in
builtins.def with proper 'fn spec' attribute.

So rather than hard-coding we should annotate more functions


> jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]