Prachi Godbole <prachi.godb...@imgtec.com> writes: > Please find the updated patch below. I hope I've covered everything. > I've added the test for inline restriction, could you check if I got all > the options correct?
I think the test is probably good enough. It is a little too forgiving due to handling the indirect call case to foo which could just detect an indirect call from foo to bar (the placement of a scan-assembler in the .c file has no impact on where in the generated output it will match in the corresponding .s). Given that the test would fail appropriately on a bare metal configuration (which is where this is likely to be most useful) then I think that is sufficient. Watch out for the long lines in comments. There is one that is hitting 80cols noted below to tweak before committing. > Changelog: > > 2017-06-23 Prachi Godbole <prachi.godb...@imgtec.com> > > gcc/ > * config/mips/mips.h (machine_function): New variable > use_hazard_barrier_return_p. > * config/mips/mips.md (UNSPEC_JRHB): New unspec. > (mips_hb_return_internal): New insn pattern. > * config/mips/mips.c (mips_attribute_table): Add attribute > use_hazard_barrier_return. > (mips_use_hazard_barrier_return_p): New static function. > (mips_function_attr_inlinable_p): Likewise. > (mips_compute_frame_info): Set use_hazard_barrier_return_p. Emit error > for unsupported architecture choice. > (mips_function_ok_for_sibcall, mips_can_use_return_insn): Return false > for use_hazard_barrier_return. > (mips_expand_epilogue): Emit hazard barrier return. > * doc/extend.texi: Document use_hazard_barrier_return. > > gcc/testsuite/ > * gcc.target/mips/hazard-barrier-return-attribute.c: New tests. OK to commit. > =================================================================== > --- gcc/config/mips/mips.c (revision 246899) > +++ gcc/config/mips/mips.c (working copy) > @@ -7863,6 +7889,17 @@ mips_function_ok_for_sibcall (tree decl, tree exp > && !targetm.binds_local_p (decl)) > return false; > + /* Functions that need to return with a hazard barrier cannot sibcall > because: Long line for a comment above. > + > + 1) Hazard barriers are not possible for direct jumps > + > + 2) Despite an indirect jump with hazard barrier being possible we do > + not use it so that the logic for generating a hazard barrier jump > + can be contained within the epilogue handling. */ > + > + if (mips_use_hazard_barrier_return_p (current_function_decl)) > + return false; > + > /* Otherwise OK. */ > return true; > } Thanks for the new feature! Matthew
