llvm dev - Nov 2020 - Work on DAG Isel for TableGen and compiler

Given that I'm only somewhat up-to-speed on the DAG ISel scheme and not much
at all on the Global ISel scheme, I'm tempted to work on the former and then
the latter. So I'll look at the CodeGenDAGPatterns messages first. Then I
will take a look at Global ISel.

Matt: Can you suggest one or two things about Global ISel that could use some
work? I won't get to it quickly, but it will give me something to focus on.


At 11/18/2020 04:17 PM, Thomas Lively wrote:
>Yes, the CodeGenDAGPatterns is exactly right. Try applying the patch below
and rebuilding and you'll see what I mean about the error messages ;) That
being said, I'm sympathetic to Matt's point about shifting effort to
GlobalISel. Maybe it has similar problems you could work on? A nicer development
experience would certainly be a good carrot to get me excited to switch over
sooner.

I would like to know why this patch https://reviews.llvm.org/D90973 had
such a drastic size effect on the global isel tablegened matcher table for
riscv.  It only changed the DAG ISel table by about 15K. But the global
isel table shrinks by over 200K.

~Craig


On Wed, Nov 18, 2020 at 1:37 PM Paul C. Anagnostopoulos via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Given that I'm only somewhat up-to-speed on the DAG ISel scheme and not
> much at all on the Global ISel scheme, I'm tempted to work on the
former
> and then the latter. So I'll look at the CodeGenDAGPatterns messages
first.
> Then I will take a look at Global ISel.
>
> Matt: Can you suggest one or two things about Global ISel that could use
> some work? I won't get to it quickly, but it will give me something to
> focus on.
>
>
> At 11/18/2020 04:17 PM, Thomas Lively wrote:
> >Yes, the CodeGenDAGPatterns is exactly right. Try applying the patch
> below and rebuilding and you'll see what I mean about the error
messages ;)
> That being said, I'm sympathetic to Matt's point about shiftingÂ
effort to
> GlobalISel. Maybe it has similar problems you could work on? A nicer
> development experience would certainly be a good carrot to get me excited
> to switch over sooner.
>
> _______________________________________________
> 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/20201118/3d3a2e28/attachment.html>

I can answer that.

The way HwModes are handled is that they are translated into macher’s
predicates.  Same selection pattern may infer different value types for
different modes, and all these variants are then predicated on the condition
defining the mode which was applied to produce the variant.  There is not much
there to common out, because the created variants are really different patterns
at this moment.

With the hw modes you can write one pattern in the .td file and get it
automatically expanded into variants instead of having to write the variants
yourself, so in that sense you still get the large matcher table one way or the
other.  Now, for the DefaultMode that your patch removes---yes, that’s both a
shortcoming of the implementation (that it’s not specified in some other way),
and that of the Hexagon .td files (that it duplicated another mode), which
inspired the RISCV’s usage.


--
Krzysztof Parzyszek  kparzysz at quicinc.com<mailto:kparzysz at
quicinc.com>   AI tools development

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Craig
Topper via llvm-dev
Sent: Thursday, November 19, 2020 12:31 AM
To: Paul C. Anagnostopoulos <paul at windfall.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] Work on DAG Isel for TableGen and compiler

I would like to know why this patch https://reviews.llvm.org/D90973 had such a
drastic size effect on the global isel tablegened matcher table for riscv.  It
only changed the DAG ISel table by about 15K. But the global isel table shrinks
by over 200K.

~Craig


On Wed, Nov 18, 2020 at 1:37 PM Paul C. Anagnostopoulos via llvm-dev
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
wrote:
Given that I'm only somewhat up-to-speed on the DAG ISel scheme and not much
at all on the Global ISel scheme, I'm tempted to work on the former and then
the latter. So I'll look at the CodeGenDAGPatterns messages first. Then I
will take a look at Global ISel.

Matt: Can you suggest one or two things about Global ISel that could use some
work? I won't get to it quickly, but it will give me something to focus on.


At 11/18/2020 04:17 PM, Thomas Lively wrote:
>Yes, the CodeGenDAGPatterns is exactly right. Try applying the patch below
and rebuilding and you'll see what I mean about the error messages ;) That
being said, I'm sympathetic to Matt's point about shifting effort to
GlobalISel. Maybe it has similar problems you could work on? A nicer development
experience would certainly be a good carrot to get me excited to switch over
sooner.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto: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/20201119/6aa601d0/attachment.html>