This is the mail archive of the gcc-patches@gcc.gnu.org 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: [patch, mips, tree] align microMIPS functions to 16 bits with -Os


Sandra Loosemore <sandra@codesourcery.com> writes:
> On 05/28/2014 01:09 PM, Richard Sandiford wrote:
>> Sandra Loosemore <sandra@codesourcery.com> writes:
>>
>>> On 05/19/2014 01:38 PM, Sandra Loosemore wrote:
>>>>
>>>> 2014-05-19  Iain Sandoe  <iain@codesourcery.com>
>>>>           Catherine Moore  <clm@codesourcery.com>
>>>>           Sandra Loosemore  <sandra@codesourcery.com>
>>>>
>>>>       gcc/
>>>>       * config/mips/mips.c (mips_set_current_function): Choose
>>>>       function alignment once the current mode is known.
>>>>
>>>>       gcc/testsuite/
>>>>       * gcc.target/mips/umips-align-1.c: New.
>>>>       * gcc.target/mips/umips-align-2.c: New.
>>>>       * gcc.target/mips/umips-align-3.c: New.
>>>>       * gcc.target/mips/mips.exp: Add interlink-compressed to
>>>>       -mfoo/-mno-foo options.
>>>
>>> Ping?
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01536.html
>>>
>>> -Sandra
>>
>> FAOD, I wasn't commenting because I still think it's the wrong place but
>> still don't have a specific counter-suggestion.  mips_set_current_function
>> is potentially called many times for the same function but setting the
>> alignment seems like something that should only happen once.  I think it
>> could potentially mean that alignment tests against the function address
>> could be optimised away based on the FUNCTION_BOUNDARY before
>> mips_set_current_function is called.
>>
>> As a strawman, maybe adding a new target hook to cgraph_create_node
>> would work?
>
> Hmmmm, why there?

I just thought trying to trap it at cgraph hand-off time would be
late enough to know the ISA mode of the function but early enough
to catch inter-function references.

>> Hopefully that'll prompt someone to say how stupid that
>> idea is and say what the right way of doing it would be.
>
> If the implementation in the current patch is considered too stupid, I'd 
> rather spend my time implementing a plausibly correct version on my next 
> try instead of another stupid one.
>
> My best guess is that this belongs somewhere in stor-layout.c, but the 
> comments on layout_decl explicitly say FUNCTION_DECLs are not handled 
> there, and I am not so familiar with the code as to be able to identify 
> all the places where FUNCTION_DECLs ought to get their storage laid out 
> but are not currently having it done.  So that's probably a stupid idea, 
> too....  :-(

I'll try asking on IRC next week.

Thanks,
Richard


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