RE: [PATCH 0/3] MIPS/GCC: Changes for `.insn' assembly annotation

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Mon, 14 Nov 2016, Matthew Fortune wrote:

> At some point in the future we may therefore have to consider backports
> of this work to pre-existing GCC releases or a configure time check in
> binutils to relax the new checks if GCC does not have the .insn fix. I
> don't know how reliable the latter will but it may be possible.

 I'm leaning towards adding `-mrelax-branch-checks' or similar GAS and LD 
options for upcoming binutils 2.28 so that people who need to run a mixed 
combination of tools or have legacy handcoded assembly code they fear to 
touch have a way to get away.  That will be some burden for some people 
I'm afraid, but the benefit is potentially problematic code will be 
identified in the default toolchain configuration right away.

 Ideally we'd optimise away branches which lead to orphan labels, as 
obviously there's as little point in executing them as there was in 
retaining the code path which has been removed from the label on.  There 
is still at least one case though where we cannot just remove the branch 
by itself as it stands as it's a part of a larger monolithic assembly 
block, i.e. the MIPS16 `casesi_internal_mips16_<mode>' insn which as I 
noted in the other submission cannot be split into smaller pieces without 
a further investigation as to why it causes too much code to be removed.

 And then there are examples like the assembly gotos I included as test 
cases where the label has to be retained by definition.  I'd expect such 
cases to be extremely rare in real code though.

  Maciej