llvm dev - Dec 2020 - Instruction namespace

I think they all target specific instructions need to be in the same
namespace. I think it's part of the instruction just to separate the target
specific instructions from the TargetOpcode instructions since otherwise
they look the same to tablegen.

getInstructionsByEnumValue() should only compute the list once and that's
probably called for other things than just getting the namespace. So I
would think only the linear scan matters. That scan has probably gotten
longer since global isel started adding G_* opcodes to the beginning of the
enum. It's ~40 without G_* and ~230 with G_*. I think the namespace could
probably be cached in CodeGenTarget.

~Craig


On Wed, Dec 2, 2020 at 10:45 AM Paul C. Anagnostopoulos via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I'm investigating a TableGen backend function named
> CodeGenTarget::getInstNamespace, which returns the instruction namespace.
> It does so by getting the instruction list sorted by enum value (yikes!)
> and then scanning it linearly for the first instruction whose namespace is
> not "TargetOpcode".
>
> This suggests that all the machine instructions are in the same namespace.
> Is that the case? If so, why have a Namespace field in the machine
> instruction? And even if there is, why not determine the namespace once and
> store it in the CodeGenTarget instance?
>
> When generating the AMDGPU instruction info, getInstNamespace is called 22
> times.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20201202/7ac20de0/attachment.html>

Yes, ComputeInstrsByEnum is called only once. getInstructionsByEnumValue is
called 62 times.

I think I will cache the namespace. There are 227 TargetOpcode instructions at
the beginning of the list. No reason to skip by those 22 times.

Is it just me, or should the TargetOpcode namespace have been called the
NontargetOpcode namespace?

At 12/2/2020 02:32 PM, Craig Topper wrote:
>I think they all target specific instructions need to be in the same
namespace. I think it's part of the instruction just to separate the target
specific instructions from the TargetOpcode instructions since otherwise they
look the same to tablegen.
>
>getInstructionsByEnumValue() should only compute the list once and
that's probably called for other things than just getting the namespace. So
I would think only the linear scan matters. That scan has probably gotten longer
since global isel started adding G_* opcodes to the beginning of the enum.
It's ~40 without G_* and ~230 with G_*. I think the namespace could probably
be cached in CodeGenTarget.