Re: [RFC PATCH] .bundle_align_mode

[Roland McGrath <mcgrathr at google dot com>]

On Wed, Feb 22, 2012 at 8:50 AM, nick clifton <nickc@redhat.com> wrote:
> No.  Well yes - a rewrite of gas, but that is not practical right now. So
> for now, frags are the way.

:-)  I also meant if there is any feasible method for avoiding the
pessimistic relaxation issue.  That is, that I wind up over-padding
unnecessarily when a relaxable instruction is close enough to a boundary
that the longest encoding doesn't fit, but relaxation winds up using a
shorter encoding that would have fit.  I take it none comes to mind.

> Personally I think that the name is a little too vague.  When I see
> "md_max_size" I think "max size of what ?".  Why not make it a little bit
> more feature specific, eg "md_max_bundle_length".

Its concrete meaning is the maximum size a given rs_machine_dependent frag
might have after relaxation.  So how about "md_frag_max_size"?

>> and optimal implementations of that hook for x86 and ARM.
>
> I have no problems with that.

I take it you mean you don't mind my suboptimal implementations.  I was
hoping for advice on how best to make them actually optimal.  (For ARM it
might well be optimal as it is.  Is there a case of a relaxable Thumb
instruction that is known a priori never to become a 4-byte instruction?)

The x86 one is definitely suboptimal, because for an unconditional jump it
says it could grow to 6 bytes, but it can in fact only ever grow to 5 bytes
(conditional jumps can grow to 6 bytes).  Ok, I think I can figure that out
with TYPE_FROM_RELAX_STATE (fr_subtype) == UNCOND_JUMP.  I'll try that and
maybe someone can confirm that it's actually reliable.


Thanks,
Roland