Sandra Loosemore <san...@codesourcery.com> writes: > On 05/28/2014 01:09 PM, Richard Sandiford wrote: >> Sandra Loosemore <san...@codesourcery.com> writes: >> >>> On 05/19/2014 01:38 PM, Sandra Loosemore wrote: >>>> >>>> 2014-05-19 Iain Sandoe <i...@codesourcery.com> >>>> Catherine Moore <c...@codesourcery.com> >>>> Sandra Loosemore <san...@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
