[PATCH] Allowing MC backends to decide relaxation based on fixup resolution

[Colin LeMahieu]

In http://reviews.llvm.org/D8217#146472, @grosbach wrote:

> In http://reviews.llvm.org/D8217#144272, @colinl wrote:
>
> > I'm definitely open to cleaner implementations.
> >
> > The issue with not doing anything in relaxInstruction() is relaxation will get stuck in an infinite loop.  The relaxation loop assumes that relaxInstruction will eventually change fixupNeedsRelaxation or mayNeedRelaxation to false.
>
>
> Yeah, we'll likely need to do something there. My inclination is do something with the target-specific fixups. Perhaps use a different fixup kind which isn't relaxable?


That's a possibility I hadn't considered before.  One concern is we wouldn't want to lose the target specific MCFixupKind so it seems like it would have to be a flag instead of a new enumeration.

One method I thought of instead of using a bool flag would simply be to pass is a maximum for Value when calling Backend::fixupNeedsRelaxation.  Conceptually this is what we're saying anyway, we don't know where this value is so it could be anywhere up to the maximum value away.

If we were to pass in some maximum value we'd have to consider if it's going to me max int64_t or max uint64_t.  During evaluateFixup it looks like the first place Value is assigned is from an int64_t and later some unsigned offsets get added but the whole value is converted to an uint64_t but what we're really expressing is a signed displacement.

Another way I didn't care for as much was having Backend::relaxInstruction return whether it relaxed the instruction.  This would still have the drawbacks of requiring all backends to change their interface and it's weird that fixupNeedsRelaxation would return true but relaxInstruction would say something different.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D8217

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/