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

Are you talking about the type checking done in CodeGenDAGPatterns.cpp? Is it
easy to post an example?

At 11/18/2020 01:55 PM, Thomas Lively wrote:
>Hi Paul,
>
>I think this would be time well spent. At least in the WebAssembly backend,
the vast majority of our ISel work is still done with DAG ISel. I know this is
different from the performance work you have in mind, but one of my biggest pain
points working on LLVM so far has been the poor error messages from the DAG ISel
pattern type checker. If you could find time to improve those error messages, I
would be extremely grateful.
>
>Thanks,
>
>Thomas

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.

--- a/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
+++ b/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
@@ -413,7 +413,7 @@ defm SHUFFLE :
 def wasm_shuffle_t : SDTypeProfile<1, 18, []>;
 def wasm_shuffle : SDNode<"WebAssemblyISD::SHUFFLE",
wasm_shuffle_t>;
 foreach vec_t = [v16i8, v8i16, v4i32, v2i64, v4f32, v2f64] in {
-def : Pat<(vec_t (wasm_shuffle (vec_t V128:$x), (vec_t V128:$y),
+def : Pat<(vec_t (wasm_shuffle V128:$x, (vec_t V128:$y),
             (i32 LaneIdx32:$m0), (i32 LaneIdx32:$m1),
             (i32 LaneIdx32:$m2), (i32 LaneIdx32:$m3),
             (i32 LaneIdx32:$m4), (i32 LaneIdx32:$m5),



On Wed, Nov 18, 2020 at 12:42 PM Paul C. Anagnostopoulos <paul at
windfall.com>
wrote:
> Are you talking about the type checking done in CodeGenDAGPatterns.cpp? Is
> it easy to post an example?
>
> At 11/18/2020 01:55 PM, Thomas Lively wrote:
> >Hi Paul,
> >
> >I think this would be time well spent. At least in the WebAssembly
> backend, the vast majority of our ISel work is still done with DAG ISel. I
> know this is different from the performance work you have in mind, but one
> of my biggest pain points working on LLVM so far has been the poor error
> messages from the DAG ISel pattern type checker. If you could find time to
> improve those error messages, I would be extremely grateful.
> >
> >Thanks,
> >
> >Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201118/8744d745/attachment.html>

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.