twister: Fix description of relationship between filter and allow/exc…

…lude

The current description of the relationship between the tests filter
and the arch/platform allow/exclude was actually incorrect.

Let's fix it.

Signed-off-by: Alberto Escolar Piedras <[email protected]>

scripts/twister

@@ -142,15 +142,6 @@ pairs:
         not (right associative)
         all comparison operators (non-associative)
 
-    arch_allow, arch_exclude, platform_allow, platform_exclude
-    are all syntactic sugar for these expressions. For instance
-
-        arch_exclude = x86 arc
-
-    Is the same as:
-
-        filter = not ARCH in ["x86", "arc"]
-
     The ':' operator compiles the string argument as a regular expression,
     and then returns a true value only if the symbol's value in the environment
     matches. For example, if CONFIG_SOC="stm32f107xc" then
@@ -159,6 +150,22 @@ pairs:
 
     Would match it.
 
+    Note that arch_allow, arch_exclude, platform_allow, platform_exclude
+    are not just syntactic sugar for filter expressions. For instance
+
+        arch_exclude = x86 arc
+
+    Can appear at first glance to have a similar effect to
+
+        filter = not ARCH in ["x86", "arc"]
+
+    but unlike "filter", these cause platforms to be filtered already during the testplan
+    generation. While "filter" does not exclue platforms at the testplan generation, and instead
+    relies on the result of running the build configuration stage. That is, to evaluate the filter
+    expression, cmake is run for that target, and then the filter evaluated as a gate for the
+    build and run steps.
+    Therefore filtering by using {platform|arch}_{exclude|allow} is much faster.
+
 The set of test cases that actually run depends on directives in the testsuite
 files and options passed in on the command line. If there is any confusion,
 running with -v or examining the test plan report (testplan.json)