[PATCH] D69077: [gicombiner] Add the MatchDag structure and parse instruction DAG's from the input

[Daniel Sanders via Phabricator via llvm-commits]

dsanders added a comment.

In D69077#1788377 <https://reviews.llvm.org/D69077#1788377>, @uweigand wrote:

> The new test case causes build bot failures (hidden by another failure that was already present):
>  http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/28934/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Aparse-match-pattern.td
>
>   /home/uweigand/sandbox/buildbot/clang-s390x-linux/llvm/llvm/test/TableGen/GICombinerEmitter/parse-match-pattern.td:212:16: error: CHECK-NEXT: expected string not found in input
>   // CHECK-NEXT: 0:$<def>, 1:mi0, 2:mi1
>                  ^
>   <stdin>:129:16: note: scanning from here
>    0:$<def>, 1:mi0, 2:mi1
>                  ^
>   <stdin>:130:2: note: possible intended match here
>    0:$<def>, 1:mi
>    ^
>  
>


I think I can hazard a reasonable guess what this one is going to be. It's probably printed in a slightly different order. I'll look into it

In D69077#1788787 <https://reviews.llvm.org/D69077#1788787>, @thakis wrote:

> The test also fails on Windows: http://45.33.8.238/win/4272/step_11.txt
>
> Looks like %p doesn't prefix pointers with 0x there.


Windows always has to be different :-). Ok, I can fix this by relaxing the regexes a bit

In D69077#1788903 <https://reviews.llvm.org/D69077#1788903>, @phosek wrote:

> We're seeing a different failure on our 2-stage bots (in second stage):
>
>   /b/s/w/ir/k/llvm-project/llvm/test/TableGen/GICombinerEmitter/parse-match-pattern.td:30:17: error: CHECK-LABEL: expected string not found in input
>   // CHECK-LABEL: Parsed rule defs/match for 'trivial'
>                   ^
>   <stdin>:1:1: note: scanning from here
>   llvm-tblgen: for the -d option: may not occur within a group!
>   ^
>   <stdin>:3:11: note: possible intended match here
>   llvm-tblgen: Did you mean '-d'?
>             ^
>  
>


Could you give me more information on this? Which bots is it? For now, I'm going to hazard a guess that the test just needs a 'REQUIRES: asserts'. Though it's a bit surprising that I don't have an email from one of the release-build bots if that were the problem


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69077/new/

https://reviews.llvm.org/D69077