[v2] LoongArch: Modify the register constraints for template "jumptable" and "indirect_jump" from "r" to "e" [PR110136]

Message ID 20230608022721.1226263-1-chenglulu@loongson.cn
State New
Headers
Series [v2] LoongArch: Modify the register constraints for template "jumptable" and "indirect_jump" from "r" to "e" [PR110136] |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 success Testing passed

Commit Message

Lulu Cheng June 8, 2023, 2:27 a.m. UTC
  Micro-architecture unconditionally treats a "jr $ra" as "return from subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch prediction.

Therefore, a problem like PR110136 can cause a significant increase in branch error
prediction rate and affect performance. The same problem exists with "indirect_jump".

gcc/ChangeLog:

	* config/loongarch/loongarch.md: Modify the register constraints for template
	"jumptable" and "indirect_jump" from "r" to "e".

Co-authored-by: Andrew Pinski <apinski@marvell.com>
---
v1 -> v2:
  1. Modify the description
  2. Modify the register constraints of the template "indirect_jump".
---
 gcc/config/loongarch/loongarch.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
  

Comments

WANG Xuerui June 8, 2023, 6:48 a.m. UTC | #1
On 2023/6/8 10:27, Lulu Cheng wrote:
> Micro-architecture unconditionally treats a "jr $ra" as "return from subroutine",
> hence doing "jr $ra" would interfere with both subroutine return prediction and
> the more general indirect branch prediction.
> 
> Therefore, a problem like PR110136 can cause a significant increase in branch error
> prediction rate and affect performance. The same problem exists with "indirect_jump".
> 
> gcc/ChangeLog:
> 
> 	* config/loongarch/loongarch.md: Modify the register constraints for template
> 	"jumptable" and "indirect_jump" from "r" to "e".
> 
> Co-authored-by: Andrew Pinski <apinski@marvell.com>
> ---
> v1 -> v2:
>    1. Modify the description
>    2. Modify the register constraints of the template "indirect_jump".
> ---
>   gcc/config/loongarch/loongarch.md | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/config/loongarch/loongarch.md b/gcc/config/loongarch/loongarch.md
> index 816a943d155..43a2ecc8957 100644
> --- a/gcc/config/loongarch/loongarch.md
> +++ b/gcc/config/loongarch/loongarch.md
> @@ -2895,6 +2895,10 @@ (define_insn "*jump_pic"
>   }
>     [(set_attr "type" "branch")])
>   
> +;; Micro-architecture unconditionally treats a "jr $ra" as "return from subroutine",
> +;; hence doing "jr $ra" would interfere with both subroutine return prediction and

Not all cases of "doing 'jr $ra'" are harmful, obviously. Paraphrasing 
it like e.g. "non-returning indirect jumps through $ra" would be better.

You could simplify the patch title a lot with this too: "Avoid 
non-returning indirect jumps through $ra" is shorter and does not 
duplicate the ChangeLog message.

> +;; the more general indirect branch prediction.
> +
>   (define_expand "indirect_jump"
>     [(set (pc) (match_operand 0 "register_operand"))]
>     ""
> @@ -2905,7 +2909,7 @@ (define_expand "indirect_jump"
>   })
>   
>   (define_insn "@indirect_jump<mode>"
> -  [(set (pc) (match_operand:P 0 "register_operand" "r"))]
> +  [(set (pc) (match_operand:P 0 "register_operand" "e"))]
>     ""
>     "jr\t%0"
>     [(set_attr "type" "jump")
> @@ -2928,7 +2932,7 @@ (define_expand "tablejump"
>   
>   (define_insn "@tablejump<mode>"
>     [(set (pc)
> -	(match_operand:P 0 "register_operand" "r"))
> +	(match_operand:P 0 "register_operand" "e"))
>      (use (label_ref (match_operand 1 "" "")))]
>     ""
>     "jr\t%0"
  

Patch

diff --git a/gcc/config/loongarch/loongarch.md b/gcc/config/loongarch/loongarch.md
index 816a943d155..43a2ecc8957 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -2895,6 +2895,10 @@  (define_insn "*jump_pic"
 }
   [(set_attr "type" "branch")])
 
+;; Micro-architecture unconditionally treats a "jr $ra" as "return from subroutine",
+;; hence doing "jr $ra" would interfere with both subroutine return prediction and
+;; the more general indirect branch prediction.
+
 (define_expand "indirect_jump"
   [(set (pc) (match_operand 0 "register_operand"))]
   ""
@@ -2905,7 +2909,7 @@  (define_expand "indirect_jump"
 })
 
 (define_insn "@indirect_jump<mode>"
-  [(set (pc) (match_operand:P 0 "register_operand" "r"))]
+  [(set (pc) (match_operand:P 0 "register_operand" "e"))]
   ""
   "jr\t%0"
   [(set_attr "type" "jump")
@@ -2928,7 +2932,7 @@  (define_expand "tablejump"
 
 (define_insn "@tablejump<mode>"
   [(set (pc)
-	(match_operand:P 0 "register_operand" "r"))
+	(match_operand:P 0 "register_operand" "e"))
    (use (label_ref (match_operand 1 "" "")))]
   ""
   "jr\t%0"