[llvm-dev] Instruction namespace
Craig Topper via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 2 11:32:49 PST 2020
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>
More information about the llvm-dev
mailing list