https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-05-04
            Version|9.0                         |5.4.1
            Summary|GCC on ARM allocates R3 for |[5,6,7,8 Regression] GCC on
                   |local variable when calling |ARM allocates R3 for local
                   |naked function with O2      |variable when calling naked
                   |optimizations enabled       |function with O2
                   |                            |optimizations enabled
     Ever confirmed|0                           |1

--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Austin Morton from comment #4)
> In my particular case I was able to work around the issue by removing the
> naked attribute and using extended assembly with a clobbers list.

Removing the naked attribute and using the extended assembler with a clobbers
list is absolutely the correct thing to do.

> 
> The resulting code is nearly identical (allowing GCC to generate the correct
> pro/epilog instead of hand writing it), and gcc correctly allocates R4
> instead of R3.
> 
> This still feels like a bug in GCC.  In the example I gave, if you compiled
> the naked function in a separate C file and linked them it would generate
> the correct code.  The issue is that GCC is able to "see" the naked function
> and is performing optimizations that it shouldn't as a result.
> 
> I believe that GCC should treat naked functions as opaque as far as
> optimizations are concerned.
> At the very least, there should be a note about this kind of issue included
> in the documentation of the naked attribute.

Yes, it should be opaque as far as this IPA-RA optimization is concerned - I
don't think there are many other optimizations that need to treat this as
opaque.  That's what I alluded to in my previous comment


> IIRC there is a hook for ipa-ra that says what
> registers can be clobbered : can't find it immediately. I suppose for naked
> functions it is *all* registers.

I wasn't looking in the backend when I responded earlier, there is no such hook
- I think the correct fix would be to get arm_emit_call_insn to mark *all*
registers as clobbered if the target of the call insn is a naked function i.e.
effectively disabling ipa-ra for naked functions. You'd have to figure out that
the DECL for the target of the call had a "naked" attribute attached to it ... 

Do you feel up to writing up a patch assuming you have copyright assignments et
al sewn up ? 




> 
> 
> 
> regards
> Ramana

Reply via email to