[RFC PATCH] .bundle_align_mode
Roland McGrath
mcgrathr@google.com
Wed Feb 22 19:21:00 GMT 2012
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
More information about the Binutils
mailing list