Searched hist:8541 (Results 1 - 23 of 23) sorted by relevance
| /gem5/src/arch/arm/isa/formats/ | ||
| H A D | mult.isa | 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| H A D | neon64.isa | 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| H A D | m5ops.isa | 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| H A D | mem.isa | 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| H A D | data.isa | 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| H A D | aarch64.isa | 12597:a2848203dcd0 Tue Mar 13 05:44:00 EDT 2018 Chun-Chen Hsu <chunchenhsu@google.com> arch, arm: Fix implicit-fallthrough GCC warnings GCC 7 generates spurious fallthrough warnings in nested switch blocks where the inner switch block return. There is already a GCC fix [1] submitted for review but, until it is merged into GCC trunk, GEM5 will not build with GCC 7 due to these fallthrough warnings. This patch silences the spurious fallthrough warnings by appending a M5_UNREACHABLE statement in the outer switch cases. Note there is another GEM5 patch [2] to fix other fallthrough warnings. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html [2] https://gem5-review.googlesource.com/c/public/gem5/+/8541 Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242 Signed-off-by: Chun-Chen Hsu <chunchenhsu@google.com> Reviewed-on: https://gem5-review.googlesource.com/9101 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| H A D | fp.isa | 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| /gem5/src/cpu/ | ||
| H A D | decode_cache.hh | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| H A D | static_inst.cc | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| H A D | static_inst.hh | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| H A D | SConscript | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| H A D | simple_thread.hh | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| H A D | thread_context.hh | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| /gem5/src/base/ | ||
| H A D | compiler.hh | 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| /gem5/src/arch/arm/insts/ | ||
| H A D | pred_inst.hh | 12595:b5a51007feac Mon Feb 19 14:02:00 EST 2018 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> arm: Fix implicit-fallthrough warnings when building with gcc-7+ gcc 7 onwards have additional heuristics to detect implicit fallthroughs and it fails the build with warnings for ARM as a result. There was one gcc bug[1] that I fixed but the rest are cases that gcc cannot detect due to the point at which it does the fallthrough check. Most of this patch adds __builtin_unreachable() hints in places that throw this warning to indicate to gcc that the fallthrough will never happen. The remaining cases are actually possible fallthroughs due to incorrect code running on the simulator; in which case an Unknown instruction is returned. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html Change-Id: I1baa9fa0ed15181c10c755c0bd777f88b607c158 Signed-off-by: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Reviewed-on: https://gem5-review.googlesource.com/8541 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| /gem5/src/arch/arm/ | ||
| H A D | remote_gdb.cc | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| /gem5/src/arch/alpha/ | ||
| H A D | remote_gdb.cc | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| /gem5/src/cpu/o3/ | ||
| H A D | thread_context.hh | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| H A D | fetch.hh | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| H A D | fetch_impl.hh | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| /gem5/src/arch/ | ||
| H A D | isa_parser.py | 12597:a2848203dcd0 Tue Mar 13 05:44:00 EDT 2018 Chun-Chen Hsu <chunchenhsu@google.com> arch, arm: Fix implicit-fallthrough GCC warnings GCC 7 generates spurious fallthrough warnings in nested switch blocks where the inner switch block return. There is already a GCC fix [1] submitted for review but, until it is merged into GCC trunk, GEM5 will not build with GCC 7 due to these fallthrough warnings. This patch silences the spurious fallthrough warnings by appending a M5_UNREACHABLE statement in the outer switch cases. Note there is another GEM5 patch [2] to fix other fallthrough warnings. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html [2] https://gem5-review.googlesource.com/c/public/gem5/+/8541 Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242 Signed-off-by: Chun-Chen Hsu <chunchenhsu@google.com> Reviewed-on: https://gem5-review.googlesource.com/9101 Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com> |
| /gem5/src/cpu/simple/ | ||
| H A D | base.hh | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
| H A D | base.cc | 8541:27aaee8ec7cc Fri Sep 09 05:30:00 EDT 2011 Gabe Black <gblack@eecs.umich.edu> Decode: Pull instruction decoding out of the StaticInst class into its own. This change pulls the instruction decoding machinery (including caches) out of the StaticInst class and puts it into its own class. This has a few intrinsic benefits. First, the StaticInst code, which has gotten to be quite large, gets simpler. Second, the code that handles decode caching is now separated out into its own component and can be looked at in isolation, making it easier to understand. I took the opportunity to restructure the code a bit which will hopefully also help. Beyond that, this change also lays some ground work for each ISA to have its own, potentially stateful decode object. We'd be able to include less contextualizing information in the ExtMachInst objects since that context would be applied at the decoder. Also, the decoder could "know" ahead of time that all the instructions it's going to see are going to be, for instance, 64 bit mode, and it will have one less thing to check when it decodes them. Because the decode caching mechanism has been separated out, it's now possible to have multiple caches which correspond to different types of decoding context. Having one cache for each element of the cross product of different configurations may become prohibitive, so it may be desirable to clear out the cache when relatively static state changes and not to have one for each setting. Because the decode function is no longer universally accessible as a static member of the StaticInst class, a new function was added to the ThreadContexts that returns the applicable decode object. |
Completed in 336 milliseconds