llvm dev - Dec 2017 - MaxTargetFixupKind -- why is it so limiting?

Hi,

I wonder why MaxTargetFixupKind  (include/llvm/MC/MCFixup.h) limiting
user-specific fixup kinds to 128 (i.e. MaxTargetFixupKind -
FirstTargetFixupKind)

  FirstTargetFixupKind = 128,

  // Limit range of target fixups, in case we want to pack more efficiently
  // later.
  MaxTargetFixupKind = (1 << 8)

May this be done backend dependent?

---
With best regards, Konstantin

How many different KINDS of fixup do you really need? As they are
target-specific, each target can indeed have 127 or 128 of them (not sure
if the max is inclusive or exclusive) - there are 20 different
"common"
ones, and I don't really see what an architecture would look like that has
a huge number more than that.

If there is a specific and useful purpose to increase them, I expect that
can be done, but my personal opinion would be that it seems unnecessary to
change this - at least without understanding what the use-case is for this.
[And should one particular architecture have an extreme number of fixup
variations, I would imagine that there are other better solutions, e.g.
grouping them into groups and then having other metadata to represent the
variant internally in that metadata].

--
Mats

On 5 December 2017 at 15:25, Konstantin Vladimirov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I wonder why MaxTargetFixupKind  (include/llvm/MC/MCFixup.h) limiting
> user-specific fixup kinds to 128 (i.e. MaxTargetFixupKind -
> FirstTargetFixupKind)
>
>   FirstTargetFixupKind = 128,
>
>   // Limit range of target fixups, in case we want to pack more efficiently
>   // later.
>   MaxTargetFixupKind = (1 << 8)
>
> May this be done backend dependent?
>
> ---
> With best regards, Konstantin
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171205/7f28495c/attachment.html>