Re: [PATCH 3b/4][AArch64] Add scheduling model for Exynos M1
On 12/04/2015 03:25 AM, Kyrill Tkachov wrote: This is ok arm-wise, sorry for the delay. Make sure to regenerate and commit the updated config/arm/arm-tune.md hunk when committing the patch. Checked in as r231378. Thank you, -- Evandro Menezes
Re: [PATCH 3b/4][AArch64] Add scheduling model for Exynos M1
Hi Evandro, On 03/12/15 20:58, Evandro Menezes wrote: On 11/20/2015 11:17 AM, James Greenhalgh wrote: On Tue, Nov 10, 2015 at 11:54:00AM -0600, Evandro Menezes wrote: 2015-11-10 Evandro Menezes gcc/ * config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. * config/aarch64/aarch64.md: Include "exynos-m1.md". * config/arm/arm-cores.def: Use the Exynos M1 sched model. * config/arm/arm.md: Include "exynos-m1.md". * config/arm/arm-tune.md: Regenerated. * config/arm/exynos-m1.md: New file. This patch adds the scheduling model for Exynos M1. It depends on https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01257.html Bootstrapped on arm-unknown-linux-gnueabihf, aarch64-unknown-linux-gnu. Please, commit if it's alright. From 0b7b6d597e5877c78c4d88e0d4491858555a5364 Mon Sep 17 00:00:00 2001 From: Evandro Menezes Date: Mon, 9 Nov 2015 17:18:52 -0600 Subject: [PATCH 2/2] [AArch64] Add scheduling model for Exynos M1 gcc/ * config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. * config/aarch64/aarch64.md: Include "exynos-m1.md". These changes are fine. * config/arm/arm-cores.def: Use the Exynos M1 sched model. * config/arm/arm.md: Include "exynos-m1.md". * config/arm/arm-tune.md: Regenerated. These changes need an ack from an ARM reviewer. * config/arm/exynos-m1.md: New file. I have a few comments on this model. +;; The Exynos M1 core is modeled as a triple issue pipeline that has +;; the following functional units. + +(define_automaton "exynos_m1_gp") +(define_automaton "exynos_m1_ls") +(define_automaton "exynos_m1_fp") + +;; 1. Two pipelines for simple integer operations: A, B +;; 2. One pipeline for simple or complex integer operations: C + +(define_cpu_unit "em1_xa, em1_xb, em1_xc" "exynos_m1_gp") + +(define_reservation "em1_alu" "(em1_xa | em1_xb | em1_xc)") +(define_reservation "em1_c" "em1_xc") Is this extra reservation useful, can we not just use em1_xc directly? +;; 3. Two asymmetric pipelines for Neon and FP operations: F0, F1 + +(define_cpu_unit "em1_f0, em1_f1" "exynos_m1_fp") + +(define_reservation "em1_fmac" "em1_f0") +(define_reservation "em1_fcvt" "em1_f0") +(define_reservation "em1_nalu" "(em1_f0 | em1_f1)") +(define_reservation "em1_nalu0" "em1_f0") +(define_reservation "em1_nalu1" "em1_f1") +(define_reservation "em1_nmisc" "em1_f0") +(define_reservation "em1_ncrypt" "em1_f0") +(define_reservation "em1_fadd" "em1_f1") +(define_reservation "em1_fvar" "em1_f1") +(define_reservation "em1_fst" "em1_f1") Same comment here, does this not just obfuscate the interaction between instruction classes in the description. I'm not against doing it this way if you prefer, but it would seem to reduce readability to me. I think there is also an argument that this increases readability, so it is your choice. + +;; 4. One pipeline for branch operations: BX + +(define_cpu_unit "em1_bx" "exynos_m1_gp") + +(define_reservation "em1_br" "em1_bx") + And again? +;; 5. One AGU for loads: L +;; One AGU for stores and one pipeline for stores: S, SD + +(define_cpu_unit "em1_lx" "exynos_m1_ls") +(define_cpu_unit "em1_sx, em1_sd" "exynos_m1_ls") + +(define_reservation "em1_ld" "em1_lx") +(define_reservation "em1_st" "(em1_sx + em1_sd)") + +;; Common occurrences +(define_reservation "em1_sfst" "(em1_fst + em1_st)") +(define_reservation "em1_lfst" "(em1_fst + em1_ld)") + +;; Branches +;; +;; No latency as there is no result +;; TODO: Unconditional branches use no units; +;; conditional branches add the BX unit; +;; indirect branches add the C unit. +(define_insn_reservation "exynos_m1_branch" 0 + (and (eq_attr "tune" "exynosm1") + (eq_attr "type" "branch")) + "em1_br") + +(define_insn_reservation "exynos_m1_call" 1 + (and (eq_attr "tune" "exynosm1") + (eq_attr "type" "call")) + "em1_alu") + +;; Basic ALU +;; +;; Simple ALU without shift, non-predicated +(define_insn_reservation "exynos_m1_alu" 1 + (and (eq_attr "tune" "exynosm1") + (and (not (eq_attr "predicated" "yes")) (and (eq_attr "predicated" "no")) ? Likewise throughout the file? Again this is your choice. This is OK from the AArch64 side, let me know if you plan to change any of the above, otherwise I'll commit it (or someone else can commit it) after I see an OK from an ARM reviewer. ARM ping. This is ok arm-wise, sorry for the delay. Make sure to regenerate and commit the updated config/arm/arm-tune.md hunk when committing the patch. Thanks, Kyrill
Re: [PATCH 3b/4][AArch64] Add scheduling model for Exynos M1
On 11/20/2015 11:17 AM, James Greenhalgh wrote: On Tue, Nov 10, 2015 at 11:54:00AM -0600, Evandro Menezes wrote: 2015-11-10 Evandro Menezes gcc/ * config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. * config/aarch64/aarch64.md: Include "exynos-m1.md". * config/arm/arm-cores.def: Use the Exynos M1 sched model. * config/arm/arm.md: Include "exynos-m1.md". * config/arm/arm-tune.md: Regenerated. * config/arm/exynos-m1.md: New file. This patch adds the scheduling model for Exynos M1. It depends on https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01257.html Bootstrapped on arm-unknown-linux-gnueabihf, aarch64-unknown-linux-gnu. Please, commit if it's alright. From 0b7b6d597e5877c78c4d88e0d4491858555a5364 Mon Sep 17 00:00:00 2001 From: Evandro Menezes Date: Mon, 9 Nov 2015 17:18:52 -0600 Subject: [PATCH 2/2] [AArch64] Add scheduling model for Exynos M1 gcc/ * config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. * config/aarch64/aarch64.md: Include "exynos-m1.md". These changes are fine. * config/arm/arm-cores.def: Use the Exynos M1 sched model. * config/arm/arm.md: Include "exynos-m1.md". * config/arm/arm-tune.md: Regenerated. These changes need an ack from an ARM reviewer. * config/arm/exynos-m1.md: New file. I have a few comments on this model. +;; The Exynos M1 core is modeled as a triple issue pipeline that has +;; the following functional units. + +(define_automaton "exynos_m1_gp") +(define_automaton "exynos_m1_ls") +(define_automaton "exynos_m1_fp") + +;; 1. Two pipelines for simple integer operations: A, B +;; 2. One pipeline for simple or complex integer operations: C + +(define_cpu_unit "em1_xa, em1_xb, em1_xc" "exynos_m1_gp") + +(define_reservation "em1_alu" "(em1_xa | em1_xb | em1_xc)") +(define_reservation "em1_c" "em1_xc") Is this extra reservation useful, can we not just use em1_xc directly? +;; 3. Two asymmetric pipelines for Neon and FP operations: F0, F1 + +(define_cpu_unit "em1_f0, em1_f1" "exynos_m1_fp") + +(define_reservation "em1_fmac" "em1_f0") +(define_reservation "em1_fcvt" "em1_f0") +(define_reservation "em1_nalu" "(em1_f0 | em1_f1)") +(define_reservation "em1_nalu0" "em1_f0") +(define_reservation "em1_nalu1" "em1_f1") +(define_reservation "em1_nmisc" "em1_f0") +(define_reservation "em1_ncrypt" "em1_f0") +(define_reservation "em1_fadd" "em1_f1") +(define_reservation "em1_fvar" "em1_f1") +(define_reservation "em1_fst" "em1_f1") Same comment here, does this not just obfuscate the interaction between instruction classes in the description. I'm not against doing it this way if you prefer, but it would seem to reduce readability to me. I think there is also an argument that this increases readability, so it is your choice. + +;; 4. One pipeline for branch operations: BX + +(define_cpu_unit "em1_bx" "exynos_m1_gp") + +(define_reservation "em1_br" "em1_bx") + And again? +;; 5. One AGU for loads: L +;; One AGU for stores and one pipeline for stores: S, SD + +(define_cpu_unit "em1_lx" "exynos_m1_ls") +(define_cpu_unit "em1_sx, em1_sd" "exynos_m1_ls") + +(define_reservation "em1_ld" "em1_lx") +(define_reservation "em1_st" "(em1_sx + em1_sd)") + +;; Common occurrences +(define_reservation "em1_sfst" "(em1_fst + em1_st)") +(define_reservation "em1_lfst" "(em1_fst + em1_ld)") + +;; Branches +;; +;; No latency as there is no result +;; TODO: Unconditional branches use no units; +;; conditional branches add the BX unit; +;; indirect branches add the C unit. +(define_insn_reservation "exynos_m1_branch" 0 + (and (eq_attr "tune" "exynosm1") + (eq_attr "type" "branch")) + "em1_br") + +(define_insn_reservation "exynos_m1_call" 1 + (and (eq_attr "tune" "exynosm1") + (eq_attr "type" "call")) + "em1_alu") + +;; Basic ALU +;; +;; Simple ALU without shift, non-predicated +(define_insn_reservation "exynos_m1_alu" 1 + (and (eq_attr "tune" "exynosm1") + (and (not (eq_attr "predicated" "yes")) (and (eq_attr "predicated" "no")) ? Likewise throughout the file? Again this is your choice. This is OK from the AArch64 side, let me know if you plan to change any of the above, otherwise I'll commit it (or someone else can commit it) after I see an OK from an ARM reviewer. ARM ping. -- Evandro Menezes
Re: [PATCH 3b/4][AArch64] Add scheduling model for Exynos M1
On 11/20/2015 11:17 AM, James Greenhalgh wrote: On Tue, Nov 10, 2015 at 11:54:00AM -0600, Evandro Menezes wrote: 2015-11-10 Evandro Menezes gcc/ * config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. * config/aarch64/aarch64.md: Include "exynos-m1.md". * config/arm/arm-cores.def: Use the Exynos M1 sched model. * config/arm/arm.md: Include "exynos-m1.md". * config/arm/arm-tune.md: Regenerated. * config/arm/exynos-m1.md: New file. This patch adds the scheduling model for Exynos M1. It depends on https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01257.html Bootstrapped on arm-unknown-linux-gnueabihf, aarch64-unknown-linux-gnu. Please, commit if it's alright. From 0b7b6d597e5877c78c4d88e0d4491858555a5364 Mon Sep 17 00:00:00 2001 From: Evandro Menezes Date: Mon, 9 Nov 2015 17:18:52 -0600 Subject: [PATCH 2/2] [AArch64] Add scheduling model for Exynos M1 gcc/ * config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. * config/aarch64/aarch64.md: Include "exynos-m1.md". These changes are fine. * config/arm/arm-cores.def: Use the Exynos M1 sched model. * config/arm/arm.md: Include "exynos-m1.md". * config/arm/arm-tune.md: Regenerated. These changes need an ack from an ARM reviewer. * config/arm/exynos-m1.md: New file. I have a few comments on this model. +;; The Exynos M1 core is modeled as a triple issue pipeline that has +;; the following functional units. + +(define_automaton "exynos_m1_gp") +(define_automaton "exynos_m1_ls") +(define_automaton "exynos_m1_fp") + +;; 1. Two pipelines for simple integer operations: A, B +;; 2. One pipeline for simple or complex integer operations: C + +(define_cpu_unit "em1_xa, em1_xb, em1_xc" "exynos_m1_gp") + +(define_reservation "em1_alu" "(em1_xa | em1_xb | em1_xc)") +(define_reservation "em1_c" "em1_xc") Is this extra reservation useful, can we not just use em1_xc directly? +;; 3. Two asymmetric pipelines for Neon and FP operations: F0, F1 + +(define_cpu_unit "em1_f0, em1_f1" "exynos_m1_fp") + +(define_reservation "em1_fmac" "em1_f0") +(define_reservation "em1_fcvt" "em1_f0") +(define_reservation "em1_nalu" "(em1_f0 | em1_f1)") +(define_reservation "em1_nalu0" "em1_f0") +(define_reservation "em1_nalu1" "em1_f1") +(define_reservation "em1_nmisc" "em1_f0") +(define_reservation "em1_ncrypt" "em1_f0") +(define_reservation "em1_fadd" "em1_f1") +(define_reservation "em1_fvar" "em1_f1") +(define_reservation "em1_fst" "em1_f1") Same comment here, does this not just obfuscate the interaction between instruction classes in the description. I'm not against doing it this way if you prefer, but it would seem to reduce readability to me. I think there is also an argument that this increases readability, so it is your choice. + +;; 4. One pipeline for branch operations: BX + +(define_cpu_unit "em1_bx" "exynos_m1_gp") + +(define_reservation "em1_br" "em1_bx") + And again? +;; 5. One AGU for loads: L +;; One AGU for stores and one pipeline for stores: S, SD + +(define_cpu_unit "em1_lx" "exynos_m1_ls") +(define_cpu_unit "em1_sx, em1_sd" "exynos_m1_ls") + +(define_reservation "em1_ld" "em1_lx") +(define_reservation "em1_st" "(em1_sx + em1_sd)") + +;; Common occurrences +(define_reservation "em1_sfst" "(em1_fst + em1_st)") +(define_reservation "em1_lfst" "(em1_fst + em1_ld)") + +;; Branches +;; +;; No latency as there is no result +;; TODO: Unconditional branches use no units; +;; conditional branches add the BX unit; +;; indirect branches add the C unit. +(define_insn_reservation "exynos_m1_branch" 0 + (and (eq_attr "tune" "exynosm1") + (eq_attr "type" "branch")) + "em1_br") + +(define_insn_reservation "exynos_m1_call" 1 + (and (eq_attr "tune" "exynosm1") + (eq_attr "type" "call")) + "em1_alu") + +;; Basic ALU +;; +;; Simple ALU without shift, non-predicated +(define_insn_reservation "exynos_m1_alu" 1 + (and (eq_attr "tune" "exynosm1") + (and (not (eq_attr "predicated" "yes")) (and (eq_attr "predicated" "no")) ? Likewise throughout the file? Again this is your choice. This is OK from the AArch64 side, let me know if you plan to change any of the above, otherwise I'll commit it (or someone else can commit it) after I see an OK from an ARM reviewer. The naming choices were made more for uniformity's sake and to conform with the processor documentation. The bit about "not... yes" <=> "no" is a goof up. :-s I'm waiting for Kyrill's patch adding FCCMP to be approved to amend this patch. However, I'd appreciate if it'd be approved and committed before then, as soon the ARM stuff is okayed. Thank you, -- Evandro Menezes
Re: [PATCH 3b/4][AArch64] Add scheduling model for Exynos M1
On Tue, Nov 10, 2015 at 11:54:00AM -0600, Evandro Menezes wrote: >2015-11-10 Evandro Menezes > >gcc/ > >* config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. >* config/aarch64/aarch64.md: Include "exynos-m1.md". >* config/arm/arm-cores.def: Use the Exynos M1 sched model. >* config/arm/arm.md: Include "exynos-m1.md". >* config/arm/arm-tune.md: Regenerated. >* config/arm/exynos-m1.md: New file. > > This patch adds the scheduling model for Exynos M1. It depends on > https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01257.html > > Bootstrapped on arm-unknown-linux-gnueabihf, aarch64-unknown-linux-gnu. > > Please, commit if it's alright. > From 0b7b6d597e5877c78c4d88e0d4491858555a5364 Mon Sep 17 00:00:00 2001 > From: Evandro Menezes > Date: Mon, 9 Nov 2015 17:18:52 -0600 > Subject: [PATCH 2/2] [AArch64] Add scheduling model for Exynos M1 > > gcc/ > * config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. > * config/aarch64/aarch64.md: Include "exynos-m1.md". These changes are fine. > * config/arm/arm-cores.def: Use the Exynos M1 sched model. > * config/arm/arm.md: Include "exynos-m1.md". > * config/arm/arm-tune.md: Regenerated. These changes need an ack from an ARM reviewer. > * config/arm/exynos-m1.md: New file. I have a few comments on this model. > +;; The Exynos M1 core is modeled as a triple issue pipeline that has > +;; the following functional units. > + > +(define_automaton "exynos_m1_gp") > +(define_automaton "exynos_m1_ls") > +(define_automaton "exynos_m1_fp") > + > +;; 1. Two pipelines for simple integer operations: A, B > +;; 2. One pipeline for simple or complex integer operations: C > + > +(define_cpu_unit "em1_xa, em1_xb, em1_xc" "exynos_m1_gp") > + > +(define_reservation "em1_alu" "(em1_xa | em1_xb | em1_xc)") > +(define_reservation "em1_c" "em1_xc") Is this extra reservation useful, can we not just use em1_xc directly? > +;; 3. Two asymmetric pipelines for Neon and FP operations: F0, F1 > + > +(define_cpu_unit "em1_f0, em1_f1" "exynos_m1_fp") > + > +(define_reservation "em1_fmac" "em1_f0") > +(define_reservation "em1_fcvt" "em1_f0") > +(define_reservation "em1_nalu" "(em1_f0 | em1_f1)") > +(define_reservation "em1_nalu0" "em1_f0") > +(define_reservation "em1_nalu1" "em1_f1") > +(define_reservation "em1_nmisc" "em1_f0") > +(define_reservation "em1_ncrypt" "em1_f0") > +(define_reservation "em1_fadd" "em1_f1") > +(define_reservation "em1_fvar" "em1_f1") > +(define_reservation "em1_fst" "em1_f1") Same comment here, does this not just obfuscate the interaction between instruction classes in the description. I'm not against doing it this way if you prefer, but it would seem to reduce readability to me. I think there is also an argument that this increases readability, so it is your choice. > + > +;; 4. One pipeline for branch operations: BX > + > +(define_cpu_unit "em1_bx" "exynos_m1_gp") > + > +(define_reservation "em1_br" "em1_bx") > + And again? > +;; 5. One AGU for loads: L > +;; One AGU for stores and one pipeline for stores: S, SD > + > +(define_cpu_unit "em1_lx" "exynos_m1_ls") > +(define_cpu_unit "em1_sx, em1_sd" "exynos_m1_ls") > + > +(define_reservation "em1_ld" "em1_lx") > +(define_reservation "em1_st" "(em1_sx + em1_sd)") > + > +;; Common occurrences > +(define_reservation "em1_sfst" "(em1_fst + em1_st)") > +(define_reservation "em1_lfst" "(em1_fst + em1_ld)") > + > +;; Branches > +;; > +;; No latency as there is no result > +;; TODO: Unconditional branches use no units; > +;; conditional branches add the BX unit; > +;; indirect branches add the C unit. > +(define_insn_reservation "exynos_m1_branch" 0 > + (and (eq_attr "tune" "exynosm1") > + (eq_attr "type" "branch")) > + "em1_br") > + > +(define_insn_reservation "exynos_m1_call" 1 > + (and (eq_attr "tune" "exynosm1") > + (eq_attr "type" "call")) > + "em1_alu") > + > +;; Basic ALU > +;; > +;; Simple ALU without shift, non-predicated > +(define_insn_reservation "exynos_m1_alu" 1 > + (and (eq_attr "tune" "exynosm1") > + (and (not (eq_attr "predicated" "yes")) (and (eq_attr "predicated" "no")) ? Likewise throughout the file? Again this is your choice. This is OK from the AArch64 side, let me know if you plan to change any of the above, otherwise I'll commit it (or someone else can commit it) after I see an OK from an ARM reviewer. Thanks, James
Re: [PATCH 3b/4][AArch64] Add scheduling model for Exynos M1
On 11/10/2015 11:54 AM, Evandro Menezes wrote: 2015-11-10 Evandro Menezes gcc/ * config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model. * config/aarch64/aarch64.md: Include "exynos-m1.md". * config/arm/arm-cores.def: Use the Exynos M1 sched model. * config/arm/arm.md: Include "exynos-m1.md". * config/arm/arm-tune.md: Regenerated. * config/arm/exynos-m1.md: New file. This patch adds the scheduling model for Exynos M1. It depends on https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01257.html Bootstrapped on arm-unknown-linux-gnueabihf, aarch64-unknown-linux-gnu. Please, commit if it's alright. Ping -- Evandro Menezes
[PATCH 3b/4][AArch64] Add scheduling model for Exynos M1
2015-11-10 Evandro Menezes
gcc/
* config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model.
* config/aarch64/aarch64.md: Include "exynos-m1.md".
* config/arm/arm-cores.def: Use the Exynos M1 sched model.
* config/arm/arm.md: Include "exynos-m1.md".
* config/arm/arm-tune.md: Regenerated.
* config/arm/exynos-m1.md: New file.
This patch adds the scheduling model for Exynos M1. It depends on
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01257.html
Bootstrapped on arm-unknown-linux-gnueabihf, aarch64-unknown-linux-gnu.
Please, commit if it's alright.
--
Evandro Menezes
>From 0b7b6d597e5877c78c4d88e0d4491858555a5364 Mon Sep 17 00:00:00 2001
From: Evandro Menezes
Date: Mon, 9 Nov 2015 17:18:52 -0600
Subject: [PATCH 2/2] [AArch64] Add scheduling model for Exynos M1
gcc/
* config/aarch64/aarch64-cores.def: Use the Exynos M1 sched model.
* config/aarch64/aarch64.md: Include "exynos-m1.md".
* config/arm/arm-cores.def: Use the Exynos M1 sched model.
* config/arm/arm.md: Include "exynos-m1.md".
* config/arm/arm-tune.md: Regenerated.
* config/arm/exynos-m1.md: New file.
---
gcc/config/aarch64/aarch64-cores.def | 2 +-
gcc/config/aarch64/aarch64.md| 1 +
gcc/config/arm/arm-cores.def | 2 +-
gcc/config/arm/arm.md| 3 +-
gcc/config/arm/exynos-m1.md | 947 +++
5 files changed, 952 insertions(+), 3 deletions(-)
create mode 100644 gcc/config/arm/exynos-m1.md
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index 0ab1ca8..c17baa3 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -43,7 +43,7 @@
AARCH64_CORE("cortex-a53", cortexa53, cortexa53, 8A, AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa53, "0x41", "0xd03")
AARCH64_CORE("cortex-a57", cortexa57, cortexa57, 8A, AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57, "0x41", "0xd07")
AARCH64_CORE("cortex-a72", cortexa72, cortexa57, 8A, AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa72, "0x41", "0xd08")
-AARCH64_CORE("exynos-m1", exynosm1, cortexa57, 8A, AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, cortexa72, "0x53", "0x001")
+AARCH64_CORE("exynos-m1", exynosm1, exynosm1, 8A, AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, cortexa72, "0x53", "0x001")
AARCH64_CORE("thunderx",thunderx, thunderx, 8A, AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx, "0x43", "0x0a1")
AARCH64_CORE("xgene1", xgene1,xgene1,8A, AARCH64_FL_FOR_ARCH8, xgene1, "0x50", "0x000")
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 2bc2ff5..18f5547 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -210,6 +210,7 @@
;; Scheduling
(include "../arm/cortex-a53.md")
(include "../arm/cortex-a57.md")
+(include "../arm/exynos-m1.md")
(include "thunderx.md")
(include "../arm/xgene1.md")
diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
index 4c35200..3448e82 100644
--- a/gcc/config/arm/arm-cores.def
+++ b/gcc/config/arm/arm-cores.def
@@ -168,7 +168,7 @@ ARM_CORE("cortex-a17.cortex-a7", cortexa17cortexa7, cortexa7, 7A, ARM_FSET_MAKE_
ARM_CORE("cortex-a53", cortexa53, cortexa53, 8A, ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_CRC32 | FL_FOR_ARCH8A), cortex_a53)
ARM_CORE("cortex-a57", cortexa57, cortexa57, 8A, ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_CRC32 | FL_FOR_ARCH8A), cortex_a57)
ARM_CORE("cortex-a72", cortexa72, cortexa57, 8A, ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_CRC32 | FL_FOR_ARCH8A), cortex_a57)
-ARM_CORE("exynos-m1", exynosm1, cortexa57, 8A, ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_CRC32 | FL_FOR_ARCH8A), cortex_a57)
+ARM_CORE("exynos-m1", exynosm1, exynosm1, 8A, ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_CRC32 | FL_FOR_ARCH8A), cortex_a57)
ARM_CORE("xgene1", xgene1,xgene1, 8A, ARM_FSET_MAKE_CPU1 (FL_LDSCHED | FL_FOR_ARCH8A),xgene1)
/* V8 big.LITTLE implementations */
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 8ebb1bf..f14cd0e 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -377,7 +377,7 @@
arm1136jfs,cortexa5,cortexa7,cortexa8,\
cortexa9,cortexa12,cortexa15,cortexa17,\
cortexa53,cortexa57,cortexm4,cortexm7,\
-marvell_pj4,xgene1")
+exynosm1,marvell_pj4,xgene1")
(eq_attr "tune_cortexr4" "yes"))
(const_string "no")
(const_string "yes"
@@ -416,6 +416,7 @@
(include "cortex-m7.md")
(include "cortex-m4.md")
(include "cortex-m4-fpu.md")
+(include "exynos-m1.md")
(include "vfp11.md")
(include "marvell-pj4.md")
(include "xgene1.md")
diff --git a/gcc/config/arm/exynos-m1.md b/gcc/config/arm/exynos-m1.md
new file mode 100644
index 000..fd73353
--- /dev/null
+++ b/gcc/config/arm/exynos-m1.md
@@ -0,0 +1,947 @@
+;;
