[U-Boot] armv5 and OMAP3 Question
The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work"
We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead.
I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC.
(please don't flame me, I am honestly curious).
adam
On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work"
We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead.
I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC.
So, these are historical notes that really should be corrected. Initially, when ARMv7 support was added, most people did not have compilers new enough to recognize -march=armv7-a. We still even support them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the options are any sort of modern gcc, llvm, ancient gcc). When we move to gcc-6 being the oldest gcc supported for ARM we can fixup those comments and logic as well.
On Tue, Jul 25, 2017 at 11:08 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work"
We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead.
I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC.
So, these are historical notes that really should be corrected. Initially, when ARMv7 support was added, most people did not have compilers new enough to recognize -march=armv7-a. We still even support them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the options are any sort of modern gcc, llvm, ancient gcc). When we move to gcc-6 being the oldest gcc supported for ARM we can fixup those comments and logic as well.
My understanding is that we've made the requirement for GCC 6 now. I just pushed a patch which enabled mtune=armv7-a-generic when CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on omap3_logic. Does it make sense to remove the , -march=armv5 from arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A implies armv-a?
adam
-- Tom
On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
On Tue, Jul 25, 2017 at 11:08 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work"
We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead.
I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC.
So, these are historical notes that really should be corrected. Initially, when ARMv7 support was added, most people did not have compilers new enough to recognize -march=armv7-a. We still even support them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the options are any sort of modern gcc, llvm, ancient gcc). When we move to gcc-6 being the oldest gcc supported for ARM we can fixup those comments and logic as well.
My understanding is that we've made the requirement for GCC 6 now. I just pushed a patch which enabled mtune=armv7-a-generic when CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on omap3_logic. Does it make sense to remove the , -march=armv5 from arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A implies armv-a?
Yes, we can probably at least drop the v5 portion of that logic. As noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a" as being the appropriate name, or at least did in the past.
On Fri, Aug 3, 2018 at 10:00 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
On Tue, Jul 25, 2017 at 11:08 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work"
We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead.
I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC.
So, these are historical notes that really should be corrected. Initially, when ARMv7 support was added, most people did not have compilers new enough to recognize -march=armv7-a. We still even support them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the options are any sort of modern gcc, llvm, ancient gcc). When we move to gcc-6 being the oldest gcc supported for ARM we can fixup those comments and logic as well.
My understanding is that we've made the requirement for GCC 6 now. I just pushed a patch which enabled mtune=armv7-a-generic when CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on omap3_logic. Does it make sense to remove the , -march=armv5 from arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A implies armv-a?
Yes, we can probably at least drop the v5 portion of that logic. As noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a" as being the appropriate name, or at least did in the past.
Can you point me to an example of how to tune armv7 for both GCC and LLVM? I was looking around and I'm not seeing an obvious syntax. I'll do a 2-part patch. One to remove the armv5, and one to enable the armv7 optimization.
adam
-- Tom
On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
On Fri, Aug 3, 2018 at 10:00 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
On Tue, Jul 25, 2017 at 11:08 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work"
We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead.
I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC.
So, these are historical notes that really should be corrected. Initially, when ARMv7 support was added, most people did not have compilers new enough to recognize -march=armv7-a. We still even support them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the options are any sort of modern gcc, llvm, ancient gcc). When we move to gcc-6 being the oldest gcc supported for ARM we can fixup those comments and logic as well.
My understanding is that we've made the requirement for GCC 6 now. I just pushed a patch which enabled mtune=armv7-a-generic when CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on omap3_logic. Does it make sense to remove the , -march=armv5 from arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A implies armv-a?
Yes, we can probably at least drop the v5 portion of that logic. As noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a" as being the appropriate name, or at least did in the past.
Can you point me to an example of how to tune armv7 for both GCC and LLVM? I was looking around and I'm not seeing an obvious syntax. I'll do a 2-part patch. One to remove the armv5, and one to enable the armv7 optimization.
In arch/arm/Makefile: arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \ $(call cc-option, -march=armv7, -march=armv5))
this works in both cases. And doc/README.clang is correct on how to build with LLVM on ARM.
On Fri, Aug 3, 2018 at 10:20 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
On Fri, Aug 3, 2018 at 10:00 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
On Tue, Jul 25, 2017 at 11:08 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work"
We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead.
I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC.
So, these are historical notes that really should be corrected. Initially, when ARMv7 support was added, most people did not have compilers new enough to recognize -march=armv7-a. We still even support them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the options are any sort of modern gcc, llvm, ancient gcc). When we move to gcc-6 being the oldest gcc supported for ARM we can fixup those comments and logic as well.
My understanding is that we've made the requirement for GCC 6 now. I just pushed a patch which enabled mtune=armv7-a-generic when CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on omap3_logic. Does it make sense to remove the , -march=armv5 from arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A implies armv-a?
Yes, we can probably at least drop the v5 portion of that logic. As noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a" as being the appropriate name, or at least did in the past.
Can you point me to an example of how to tune armv7 for both GCC and LLVM? I was looking around and I'm not seeing an obvious syntax. I'll do a 2-part patch. One to remove the armv5, and one to enable the armv7 optimization.
In arch/arm/Makefile: arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \ $(call cc-option, -march=armv7, -march=armv5))
this works in both cases. And doc/README.clang is correct on how to build with LLVM on ARM.
I reset my head to origin/master, but using the following, I am not able to build omap3_logic with clang on Ubuntu 18.04:
make HOSTCC=clang omap3_logic make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \ CC="clang -target arm-linux-gnueabi" -j8
arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time. ^ arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT block ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go. ^ arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:56:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:103:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3} ^ arch/arm/lib/memset.S:105:2: error: predicated instructions must be in IT block strne r1, [ip], #4 ^ arch/arm/lib/memset.S:111:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:112:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:114:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:120:2: error: predicated instructions must be in IT block strblt r1, [ip], #1 @ 1 ^ arch/arm/lib/memset.S:121:2: error: predicated instructions must be in IT block strble r1, [ip], #1 @ 1 ^ scripts/Makefile.build:314: recipe for target 'arch/arm/lib/memset.o' failed make[1]: *** [arch/arm/lib/memset.o] Error 1 Makefile:1373: recipe for target 'arch/arm/lib' failed make: *** [arch/arm/lib] Error 2 aford@aford-IdeaCentre-A730:~/src/u-boot$
If you have any suggestions, I'm open to try them. I have never used clang before, but I would really like to get these armv7a optimizations in to make SPL smaller.
adam
-- Tom
On Sat, Aug 04, 2018 at 05:32:18AM -0500, Adam Ford wrote:
On Fri, Aug 3, 2018 at 10:20 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
On Fri, Aug 3, 2018 at 10:00 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
On Tue, Jul 25, 2017 at 11:08 AM Tom Rini trini@konsulko.com wrote:
On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote:
> The readme file for OMAP indicates that we compile using armv5 to "to > allow more compilers to work" > > We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting > some special assembly insturctions becuse we use armv5. The barriers > defined also indicate we're using CP15 instead of the separate barrier > instructions for armv7 because we're using armv5 instead. > > I just wonder in this day and age when we're noting a GCC version and > generating warnings based on the GCC warning, do we still need to > compile as armv5 any more? It seems like "to allow more compilers to > work" would not really apply any more we're trying to push newer > versions of GCC.
So, these are historical notes that really should be corrected. Initially, when ARMv7 support was added, most people did not have compilers new enough to recognize -march=armv7-a. We still even support them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the options are any sort of modern gcc, llvm, ancient gcc). When we move to gcc-6 being the oldest gcc supported for ARM we can fixup those comments and logic as well.
My understanding is that we've made the requirement for GCC 6 now. I just pushed a patch which enabled mtune=armv7-a-generic when CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on omap3_logic. Does it make sense to remove the , -march=armv5 from arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A implies armv-a?
Yes, we can probably at least drop the v5 portion of that logic. As noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a" as being the appropriate name, or at least did in the past.
Can you point me to an example of how to tune armv7 for both GCC and LLVM? I was looking around and I'm not seeing an obvious syntax. I'll do a 2-part patch. One to remove the armv5, and one to enable the armv7 optimization.
In arch/arm/Makefile: arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \ $(call cc-option, -march=armv7, -march=armv5))
this works in both cases. And doc/README.clang is correct on how to build with LLVM on ARM.
I reset my head to origin/master, but using the following, I am not able to build omap3_logic with clang on Ubuntu 18.04:
make HOSTCC=clang omap3_logic make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \ CC="clang -target arm-linux-gnueabi" -j8
arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time. ^ arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT block ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go. ^ arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:56:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:103:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3} ^ arch/arm/lib/memset.S:105:2: error: predicated instructions must be in IT block strne r1, [ip], #4 ^ arch/arm/lib/memset.S:111:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:112:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:114:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:120:2: error: predicated instructions must be in IT block strblt r1, [ip], #1 @ 1 ^ arch/arm/lib/memset.S:121:2: error: predicated instructions must be in IT block strble r1, [ip], #1 @ 1 ^ scripts/Makefile.build:314: recipe for target 'arch/arm/lib/memset.o' failed make[1]: *** [arch/arm/lib/memset.o] Error 1 Makefile:1373: recipe for target 'arch/arm/lib' failed make: *** [arch/arm/lib] Error 2 aford@aford-IdeaCentre-A730:~/src/u-boot$
If you have any suggestions, I'm open to try them. I have never used clang before, but I would really like to get these armv7a optimizations in to make SPL smaller.
I guess I forgot that you will need to turn off ARCH_MEMCPY/ARCH_MEMSET and EFI support for clang. That said, since you're just making sure the right options are being passed in, in both cases, you can also just use V=1 and just build common/main.o or something like that.
On Sat, Aug 4, 2018 at 6:44 AM Tom Rini trini@konsulko.com wrote:
On Sat, Aug 04, 2018 at 05:32:18AM -0500, Adam Ford wrote:
On Fri, Aug 3, 2018 at 10:20 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
On Fri, Aug 3, 2018 at 10:00 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote:
On Tue, Jul 25, 2017 at 11:08 AM Tom Rini trini@konsulko.com wrote: > > On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote: > > > The readme file for OMAP indicates that we compile using armv5 to "to > > allow more compilers to work" > > > > We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting > > some special assembly insturctions becuse we use armv5. The barriers > > defined also indicate we're using CP15 instead of the separate barrier > > instructions for armv7 because we're using armv5 instead. > > > > I just wonder in this day and age when we're noting a GCC version and > > generating warnings based on the GCC warning, do we still need to > > compile as armv5 any more? It seems like "to allow more compilers to > > work" would not really apply any more we're trying to push newer > > versions of GCC. > > So, these are historical notes that really should be corrected. > Initially, when ARMv7 support was added, most people did not have > compilers new enough to recognize -march=armv7-a. We still even support > them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the > options are any sort of modern gcc, llvm, ancient gcc). When we move to > gcc-6 being the oldest gcc supported for ARM we can fixup those comments > and logic as well.
My understanding is that we've made the requirement for GCC 6 now. I just pushed a patch which enabled mtune=armv7-a-generic when CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on omap3_logic. Does it make sense to remove the , -march=armv5 from arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A implies armv-a?
Yes, we can probably at least drop the v5 portion of that logic. As noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a" as being the appropriate name, or at least did in the past.
Can you point me to an example of how to tune armv7 for both GCC and LLVM? I was looking around and I'm not seeing an obvious syntax. I'll do a 2-part patch. One to remove the armv5, and one to enable the armv7 optimization.
In arch/arm/Makefile: arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \ $(call cc-option, -march=armv7, -march=armv5))
this works in both cases. And doc/README.clang is correct on how to build with LLVM on ARM.
I reset my head to origin/master, but using the following, I am not able to build omap3_logic with clang on Ubuntu 18.04:
make HOSTCC=clang omap3_logic make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \ CC="clang -target arm-linux-gnueabi" -j8
arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time. ^ arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT block ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go. ^ arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:56:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:103:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3} ^ arch/arm/lib/memset.S:105:2: error: predicated instructions must be in IT block strne r1, [ip], #4 ^ arch/arm/lib/memset.S:111:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:112:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:114:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:120:2: error: predicated instructions must be in IT block strblt r1, [ip], #1 @ 1 ^ arch/arm/lib/memset.S:121:2: error: predicated instructions must be in IT block strble r1, [ip], #1 @ 1 ^ scripts/Makefile.build:314: recipe for target 'arch/arm/lib/memset.o' failed make[1]: *** [arch/arm/lib/memset.o] Error 1 Makefile:1373: recipe for target 'arch/arm/lib' failed make: *** [arch/arm/lib] Error 2 aford@aford-IdeaCentre-A730:~/src/u-boot$
If you have any suggestions, I'm open to try them. I have never used clang before, but I would really like to get these armv7a optimizations in to make SPL smaller.
I guess I forgot that you will need to turn off ARCH_MEMCPY/ARCH_MEMSET and EFI support for clang. That said, since you're just making sure the right options are being passed in, in both cases, you can also just use V=1 and just build common/main.o or something like that.
I am not getting compiler errors due to the-mtune=generic-armv7-a on clang, or at least the clang version that comes with Ubuntu 18.04
clang -target arm-none-eabi -Wp,-MD,common/.main.o.d -nostdinc -isystem /usr/lib/llvm-6.0/lib/clang/6.0.0/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Qunused-arguments -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -std=gnu11 -fshort-wchar -Os -fno-stack-protector -g -Wno-format-nonliteral -Wno-format-invalid-specifier -Wno-gnu -Wno-address-of-packed-member -Werror=date-time -D__ARM__ -marm -mabi=aapcs-linux -fno-pic -mno-unaligned-access -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -mno-movt -pipe -march=armv7-a -D__LINUX_ARM_ARCH__=7 -mtune=generic-armv7-a -I./arch/arm/mach-omap2/include -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(main)" -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o common/main.o common/main.c
aford@aford-IdeaCentre-A730:~/src/u-boot$ arm-linux-gnueabi-size common/main.o text data bss dec hex filename 181 0 0 181 b5 common/main.o
If this is good enough for you, I'd like to push a patch that removes the armv5 reference in the Makefile, adds mtune to the Makefile and removes the armv5 reference in doc/README.omap3.
Stock text data bss dec hex filename 50910 429 67580 118919 1d087 spl/u-boot-spl 540713 22700 327072 890485 d9675 u-boot
Without Armv5 text data bss dec hex filename 50916 429 67580 118925 1d08d spl/u-boot-spl 540719 22700 327064 890483 d9673 u-boot
-mtune=generic-armv7-a text data bss dec hex filename 50932 429 67580 118941 1d09d spl/u-boot-spl 540519 22700 327080 890299 d95bb u-boot
SPL grew a little, but U-Boot seems to shrink (with GCC)
I don't know much about the omap3 assembly code found in Lowlevel_init.S, but I was hoping someone might know a better way to optimize (or eliminate) it.
adam
-- Tom
On Sat, Aug 04, 2018 at 09:39:12AM -0500, Adam Ford wrote:
On Sat, Aug 4, 2018 at 6:44 AM Tom Rini trini@konsulko.com wrote:
On Sat, Aug 04, 2018 at 05:32:18AM -0500, Adam Ford wrote:
On Fri, Aug 3, 2018 at 10:20 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 10:02:17AM -0500, Adam Ford wrote:
On Fri, Aug 3, 2018 at 10:00 AM Tom Rini trini@konsulko.com wrote:
On Fri, Aug 03, 2018 at 05:43:46AM -0500, Adam Ford wrote: > On Tue, Jul 25, 2017 at 11:08 AM Tom Rini trini@konsulko.com wrote: > > > > On Tue, Jul 25, 2017 at 08:14:57AM -0500, Adam Ford wrote: > > > > > The readme file for OMAP indicates that we compile using armv5 to "to > > > allow more compilers to work" > > > > > > We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting > > > some special assembly insturctions becuse we use armv5. The barriers > > > defined also indicate we're using CP15 instead of the separate barrier > > > instructions for armv7 because we're using armv5 instead. > > > > > > I just wonder in this day and age when we're noting a GCC version and > > > generating warnings based on the GCC warning, do we still need to > > > compile as armv5 any more? It seems like "to allow more compilers to > > > work" would not really apply any more we're trying to push newer > > > versions of GCC. > > > > So, these are historical notes that really should be corrected. > > Initially, when ARMv7 support was added, most people did not have > > compilers new enough to recognize -march=armv7-a. We still even support > > them, see the logic in arch/arm/Makefile around CONFIG_CPU_V7 (the > > options are any sort of modern gcc, llvm, ancient gcc). When we move to > > gcc-6 being the oldest gcc supported for ARM we can fixup those comments > > and logic as well. > > My understanding is that we've made the requirement for GCC 6 now. I > just pushed a patch which enabled mtune=armv7-a-generic when > CONFIG_CPU_V7A is enabled and that seems to shrink the code a bit on > omap3_logic. Does it make sense to remove the , -march=armv5 from > arch/arm/Makefile and or the plain -march=armv7 since CONFIG_CPU_V7A > implies armv-a?
Yes, we can probably at least drop the v5 portion of that logic. As noted in the other patch, LLVM and GCC disagree on "armv7" vs "armv7-a" as being the appropriate name, or at least did in the past.
Can you point me to an example of how to tune armv7 for both GCC and LLVM? I was looking around and I'm not seeing an obvious syntax. I'll do a 2-part patch. One to remove the armv5, and one to enable the armv7 optimization.
In arch/arm/Makefile: arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \ $(call cc-option, -march=armv7, -march=armv5))
this works in both cases. And doc/README.clang is correct on how to build with LLVM on ARM.
I reset my head to origin/master, but using the following, I am not able to build omap3_logic with clang on Ubuntu 18.04:
make HOSTCC=clang omap3_logic make HOSTCC=clang CROSS_COMPILE=arm-linux-gnueabi- \ CC="clang -target arm-linux-gnueabi" -j8
arch/arm/lib/memset.S:43:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} @ 64 bytes at a time. ^ arch/arm/lib/memset.S:44:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:45:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:46:2: error: predicated instructions must be in IT block stmiage ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:48:2: error: predicated instructions must be in IT block ldmfdeq sp!, {r8, pc} @ Now <64 bytes to go. ^ arch/arm/lib/memset.S:53:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:54:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:56:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3, r8, lr} ^ arch/arm/lib/memset.S:103:2: error: predicated instructions must be in IT block stmiane ip!, {r1, r3} ^ arch/arm/lib/memset.S:105:2: error: predicated instructions must be in IT block strne r1, [ip], #4 ^ arch/arm/lib/memset.S:111:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:112:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:114:2: error: predicated instructions must be in IT block strbne r1, [ip], #1 ^ arch/arm/lib/memset.S:120:2: error: predicated instructions must be in IT block strblt r1, [ip], #1 @ 1 ^ arch/arm/lib/memset.S:121:2: error: predicated instructions must be in IT block strble r1, [ip], #1 @ 1 ^ scripts/Makefile.build:314: recipe for target 'arch/arm/lib/memset.o' failed make[1]: *** [arch/arm/lib/memset.o] Error 1 Makefile:1373: recipe for target 'arch/arm/lib' failed make: *** [arch/arm/lib] Error 2 aford@aford-IdeaCentre-A730:~/src/u-boot$
If you have any suggestions, I'm open to try them. I have never used clang before, but I would really like to get these armv7a optimizations in to make SPL smaller.
I guess I forgot that you will need to turn off ARCH_MEMCPY/ARCH_MEMSET and EFI support for clang. That said, since you're just making sure the right options are being passed in, in both cases, you can also just use V=1 and just build common/main.o or something like that.
I am not getting compiler errors due to the-mtune=generic-armv7-a on clang, or at least the clang version that comes with Ubuntu 18.04
clang -target arm-none-eabi -Wp,-MD,common/.main.o.d -nostdinc -isystem /usr/lib/llvm-6.0/lib/clang/6.0.0/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Qunused-arguments -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -std=gnu11 -fshort-wchar -Os -fno-stack-protector -g -Wno-format-nonliteral -Wno-format-invalid-specifier -Wno-gnu -Wno-address-of-packed-member -Werror=date-time -D__ARM__ -marm -mabi=aapcs-linux -fno-pic -mno-unaligned-access -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -mno-movt -pipe -march=armv7-a -D__LINUX_ARM_ARCH__=7 -mtune=generic-armv7-a -I./arch/arm/mach-omap2/include -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(main)" -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o common/main.o common/main.c
aford@aford-IdeaCentre-A730:~/src/u-boot$ arm-linux-gnueabi-size common/main.o text data bss dec hex filename 181 0 0 181 b5 common/main.o
If this is good enough for you, I'd like to push a patch that removes the armv5 reference in the Makefile, adds mtune to the Makefile and removes the armv5 reference in doc/README.omap3.
Stock text data bss dec hex filename 50910 429 67580 118919 1d087 spl/u-boot-spl 540713 22700 327072 890485 d9675 u-boot
Without Armv5 text data bss dec hex filename 50916 429 67580 118925 1d08d spl/u-boot-spl 540719 22700 327064 890483 d9673 u-boot
-mtune=generic-armv7-a text data bss dec hex filename 50932 429 67580 118941 1d09d spl/u-boot-spl 540519 22700 327080 890299 d95bb u-boot
SPL grew a little, but U-Boot seems to shrink (with GCC)
I don't know much about the omap3 assembly code found in Lowlevel_init.S, but I was hoping someone might know a better way to optimize (or eliminate) it.
Sounds good, thanks for digging into this!
participants (2)
-
Adam Ford -
Tom Rini