subtle side effect of commit a1c48bb160f836

DISCUSSION Vineet Gupta 3 participants 16 messages Jun 18, 2015 – Jul 3, 2015

Subsystems (2)

Generic include/asm header files Synopsys ARC architecture

lore

Share & tools

lore

Vineet Gupta

author

2015-06-18 06:55 UTC #0 lore raw

Hi Geert,

commit a1c48bb160f8368 "Makefile: Fix unrecognized cross-compiler command line options" moved ARCH specific cc option handling before common -Os/O2 setup.

For ARC this had a subtle effect that we can no longer over-ride generic -O2 with -O3, hence a performance regression observed going from 3.13 to 3.18 (the above commit went into 3.16)

I want to understand how to properly fix this. Moving the include of arch makefile will bring back the old issue. I can introduce another option to set default optim level, but only arc/m32r care about it anyways.

Thx,
-Vineet

Geert Uytterhoeven

2015-06-18 07:10 UTC #1 lore raw

Hi Vineet,

Quoted 10 lines · Vineet Gupta

commit a1c48bb160f8368 "Makefile: Fix unrecognized cross-compiler command line options" moved ARCH specific cc option handling before common -Os/O2 setup.
For ARC this had a subtle effect that we can no longer over-ride generic -O2 with -O3, hence a performance regression observed going from 3.13 to 3.18 (the above commit went into 3.16)
I want to understand how to properly fix this. Moving the include of arch makefile will bring back the old issue. I can introduce another option to set default optim level, but only arc/m32r care about it anyways.

Can we include $(srctree)/arch/$(SRCARCH)/Makefile twice?

Or perhaps we can not apply the extra -O* if there's already a -O* option?

Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Vineet Gupta

author

2015-06-18 07:33 UTC #2 lore raw

Quoted 5 lines · Geert Uytterhoeven

Quoted 3 lines · Vineet Gupta
Quoted 3 lines
commit a1c48bb160f8368 "Makefile: Fix unrecognized cross-compiler command line options" moved ARCH specific cc option handling before common -Os/O2 setup.

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
For ARC this had a subtle effect that we can no longer over-ride generic -O2 with -O3, hence a performance regression observed going from 3.13 to 3.18 (the above commit went into 3.16)
I want to understand how to properly fix this. Moving the include of arch makefile will bring back the old issue. I can introduce another option to set default optim level, but only arc/m32r care about it anyways.
Can we include $(srctree)/arch/$(SRCARCH)/Makefile twice?

Something like this would be ideal, but does that not bring back your warnings ?

Quoted 2 lines

Or perhaps we can not apply the extra -O* if there's already a -O* option?

Could be, but I'm not sure how to do that ?

Quoted 2 lines

Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.

I can cook this one - but is it really worth doing when only 2 arches care.

Michal, do you have any opinion on how to solve this ?

-Vineet

Geert Uytterhoeven

2015-06-18 07:37 UTC #3 lore raw

Quoted 10 lines · Vineet Gupta

Quoted 9 lines · Geert Uytterhoeven
Quoted 7 lines · Vineet Gupta
Quoted 7 lines
commit a1c48bb160f8368 "Makefile: Fix unrecognized cross-compiler command line options" moved ARCH specific cc option handling before common -Os/O2 setup.
For ARC this had a subtle effect that we can no longer over-ride generic -O2 with -O3, hence a performance regression observed going from 3.13 to 3.18 (the above commit went into 3.16)

Quoted 6 lines

Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
I want to understand how to properly fix this. Moving the include of arch makefile will bring back the old issue. I can introduce another option to set default optim level, but only arc/m32r care about it anyways.
Can we include $(srctree)/arch/$(SRCARCH)/Makefile twice?
Something like this would be ideal, but does that not bring back your warnings ?

I don't think so. The warnings were caused by using the host compiler instead of the cross compiler while checking for the support of some compiler options.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Vineet Gupta

author

2015-06-18 08:00 UTC #4 lore raw

Quoted 5 lines · Geert Uytterhoeven

Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Can we include $(srctree)/arch/$(SRCARCH)/Makefile twice?
Something like this would be ideal, but does that not bring back your warnings ?
I don't think so. The warnings were caused by using the host compiler instead of the cross compiler while checking for the support of some compiler options.

Tried that but build system spews tons of warning about over-riding commands...

----->8-------
arch/arc/Makefile:103: warning: overriding commands for target uImage' arch/arc/Makefile:103: warning: ignoring old commands for target uImage' arch/arc/Makefile:103: warning: overriding commands for target uImage.bin' arch/arc/Makefile:103: warning: ignoring old commands for target uImage.bin'
...
...
----->8-------

Michal Marek

2015-06-18 08:13 UTC #5 lore raw

In reply to Geert Uytterhoeven

Quoted 14 lines · Geert Uytterhoeven

Hi Vineet,
Quoted 10 lines · Vineet Gupta
commit a1c48bb160f8368 "Makefile: Fix unrecognized cross-compiler command line options" moved ARCH specific cc option handling before common -Os/O2 setup.
For ARC this had a subtle effect that we can no longer over-ride generic -O2 with -O3, hence a performance regression observed going from 3.13 to 3.18 (the above commit went into 3.16)
I want to understand how to properly fix this. Moving the include of arch makefile will bring back the old issue. I can introduce another option to set default optim level, but only arc/m32r care about it anyways.

m32r only sets -O for its assembler.

Quoted 1 line

Can we include $(srctree)/arch/$(SRCARCH)/Makefile twice?

Please don't, the gcc commandline is long enough already.

Quoted 4 lines

Or perhaps we can not apply the extra -O* if there's already a -O* option?
Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.

We can also introduce some ARCH_CFLAGS that is appended near the end of the list, and have arc/Makefile add its -O3 there. But I'd like to why the -O3 needs to be there in first place. Obviously, the kernel works with -O2, otherwise the regression would have been identified earlier. So why can't users specify -O3 in KCFLAGS like on any other architecture.

Michal

Vineet Gupta

author

2015-06-18 08:46 UTC #6 lore raw

Quoted 5 lines · Michal Marek

Quoted 2 lines
Quoted 2 lines
Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.
We can also introduce some ARCH_CFLAGS that is appended near the end of the list, and have arc/Makefile add its -O3 there. But I'd like to why the -O3 needs to be there in first place.

This is how historically ARC kernels have been built. We do track performance results LMBench/hackbench... and going from -O3 to -O2 caused a sudden dip in some of the numbers when we measured 3.18 (vs. 3.13)

Quoted 2 lines

Obviously, the kernel works
with -O2, otherwise the regression would have been identified earlier.

Its a performance thing - so yeah -O2 works, but -O3 works even better :-)

Quoted 2 lines

So why can't users specify -O3 in KCFLAGS like on any other architecture.

Sweet, I didn't know about this. But I don't see any arch setting this - only tile using it. So yeah - below does the trick !

--------->
From 5e44cd2ed69b1d030b4cb87600d2767b69c35537 Mon Sep 17 00:00:00 2001
From: Vineet Gupta <[email protected]>
Date: Thu, 18 Jun 2015 13:54:01 +0530
Subject: [PATCH] ARC: Override toplevel default -O2 with -O3

ARC kernels have historically been built with -O3, despite top level Makefile defaulting to -O2. This was facilitated by implicitly ordering of arch makefile include AFTER top level assigned -O2.

An upstream fix to top level a1c48bb160f ("Makefile: Fix unrecognized cross-compiler command line options") changed the ordering, making ARC -O3 defunt.

Fix that by NOT relying on any ordering whatsoever and use the right mechanism to do the over-rides.

Cc Geert Uytterhoeven <[email protected]>

Cc <[email protected]>

Signed-off-by Vineet Gupta <[email protected]>

---
 arch/arc/Makefile | 1 +
 1 file changed, 1 insertion(+)

arch/arc/Makefile +1 -0

index 86c71b2089d2..c23f3f2b0ff8 100644
@@ -44,6 +44,7 @@ endif
 ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
 # Generic build system uses -O2, we want -O3
 cflags-y  += -O3
+KCFLAGS += -O3
 endif
 
 # small data is default for elf32 tool-chain. If not usable, disable it

Signature · 1 line

1.9.1

Geert Uytterhoeven

2015-06-18 08:55 UTC #7 lore raw

Hi Vineet,

Quoted 7 lines · Vineet Gupta

Quoted 5 lines · Michal Marek
Quoted 2 lines
Quoted 2 lines
Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.
We can also introduce some ARCH_CFLAGS that is appended near the end of the list, and have arc/Makefile add its -O3 there. But I'd like to why the -O3 needs to be there in first place.

Quoted 8 lines

This is how historically ARC kernels have been built. We do track performance results LMBench/hackbench... and going from -O3 to -O2 caused a sudden dip in some of the numbers when we measured 3.18 (vs. 3.13)
Quoted 2 lines
Obviously, the kernel works
with -O2, otherwise the regression would have been identified earlier.
Its a performance thing - so yeah -O2 works, but -O3 works even better :-)

Did you see some numbers increase when going from -O3 to -O2? IIRC, -O3 enables more aggressive inlining, which can cause more L1 cache misses.

It might be worth trying CONFIG_CC_OPTIMIZE_FOR_SIZE=y...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Vineet Gupta

author

2015-06-18 09:17 UTC #8 lore raw

+CC Claudiu - ARC gcc guru

Quoted 15 lines · Geert Uytterhoeven

Hi Vineet,
Quoted 11 lines · Vineet Gupta
Quoted 5 lines · Michal Marek
Quoted 2 lines
Quoted 2 lines
Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.
We can also introduce some ARCH_CFLAGS that is appended near the end of the list, and have arc/Makefile add its -O3 there. But I'd like to why the -O3 needs to be there in first place.
This is how historically ARC kernels have been built. We do track performance results LMBench/hackbench... and going from -O3 to -O2 caused a sudden dip in some of the numbers when we measured 3.18 (vs. 3.13)

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
Obviously, the kernel works
with -O2, otherwise the regression would have been identified earlier.
Its a performance thing - so yeah -O2 works, but -O3 works even better :-)
Did you see some numbers increase when going from -O3 to -O2? IIRC, -O3 enables more aggressive inlining, which can cause more L1 cache misses.

It sure does but smaller functions could cause more stack return mispredicts etc. It all boils down to the micro-arch in the end and how gcc does arch specific things under the hood of -O{2,s}.

Quoted 1 line

It might be worth trying CONFIG_CC_OPTIMIZE_FOR_SIZE=y...

Not for ARC. At -Os gcc is more worried about using short instructions (2 bytes), and things like alignment of target branches, ld/st scheduling might not be as optim as with -O2/O3. Some of the code density instructions have associated pipeline stalls etc.

So last time (it's been a while though) when I ran benchmarks with -Os on ARC, it was way off vs. -O2.

Michal Marek

2015-06-18 10:14 UTC #9 lore raw

In reply to Vineet Gupta

Dne 18.6.2015 v 10:45 Vineet Gupta napsal(a):

Quoted 52 lines · Michal Marek

Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.
We can also introduce some ARCH_CFLAGS that is appended near the end of the list, and have arc/Makefile add its -O3 there. But I'd like to why the -O3 needs to be there in first place.
This is how historically ARC kernels have been built. We do track performance results LMBench/hackbench... and going from -O3 to -O2 caused a sudden dip in some of the numbers when we measured 3.18 (vs. 3.13)
Quoted 2 lines
Obviously, the kernel works
with -O2, otherwise the regression would have been identified earlier.
Its a performance thing - so yeah -O2 works, but -O3 works even better :-)
Quoted 2 lines
So why can't users specify -O3 in KCFLAGS like on any other architecture.
Sweet, I didn't know about this. But I don't see any arch setting this - only tile using it. So yeah - below does the trick !
--------->
From 5e44cd2ed69b1d030b4cb87600d2767b69c35537 Mon Sep 17 00:00:00 2001
From: Vineet Gupta <[email protected]>
Date: Thu, 18 Jun 2015 13:54:01 +0530
Subject: [PATCH] ARC: Override toplevel default -O2 with -O3
ARC kernels have historically been built with -O3, despite top level Makefile defaulting to -O2. This was facilitated by implicitly ordering of arch makefile include AFTER top level assigned -O2.
An upstream fix to top level a1c48bb160f ("Makefile: Fix unrecognized cross-compiler command line options") changed the ordering, making ARC -O3 defunt.
Fix that by NOT relying on any ordering whatsoever and use the right mechanism to do the over-rides.
Suggested-by Michal Marek <[email protected]>
Cc Geert Uytterhoeven <[email protected]>
Cc <[email protected]>
Signed-off-by Vineet Gupta <[email protected]>
---
 arch/arc/Makefile | 1 +
 1 file changed, 1 insertion(+)
arch/arc/Makefile +0 -0
index 86c71b2089d2..c23f3f2b0ff8 100644

arch/arc/Makefile endif · line 48

Quoted 5 lines

arch/arc/Makefile +1 -0

@@ -44,6 +44,7 @@ endif
 ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
 # Generic build system uses -O2, we want -O3
 cflags-y  += -O3
+KCFLAGS += -O3
 endif

Uh, this is not what I meant. KCFLAGS is a *user* setting. It's meant to be set in the environment or command line.

Michal

Vineet Gupta

author

2015-06-18 10:33 UTC #10 lore raw

Quoted 48 lines · Michal Marek

Dne 18.6.2015 v 10:45 Vineet Gupta napsal(a):
Quoted 47 lines
Quoted 47 lines · Michal Marek
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.
We can also introduce some ARCH_CFLAGS that is appended near the end of the list, and have arc/Makefile add its -O3 there. But I'd like to why the -O3 needs to be there in first place.
This is how historically ARC kernels have been built. We do track performance results LMBench/hackbench... and going from -O3 to -O2 caused a sudden dip in some of the numbers when we measured 3.18 (vs. 3.13)
Quoted 2 lines
Quoted 2 lines
Obviously, the kernel works
with -O2, otherwise the regression would have been identified earlier.
Its a performance thing - so yeah -O2 works, but -O3 works even better :-)
Quoted 2 lines
Quoted 2 lines
So why can't users specify -O3 in KCFLAGS like on any other architecture.
Sweet, I didn't know about this. But I don't see any arch setting this - only tile using it. So yeah - below does the trick !
--------->
From 5e44cd2ed69b1d030b4cb87600d2767b69c35537 Mon Sep 17 00:00:00 2001
From: Vineet Gupta <[email protected]>
Date: Thu, 18 Jun 2015 13:54:01 +0530
Subject: [PATCH] ARC: Override toplevel default -O2 with -O3
ARC kernels have historically been built with -O3, despite top level Makefile defaulting to -O2. This was facilitated by implicitly ordering of arch makefile include AFTER top level assigned -O2.
An upstream fix to top level a1c48bb160f ("Makefile: Fix unrecognized cross-compiler command line options") changed the ordering, making ARC -O3 defunt.
Fix that by NOT relying on any ordering whatsoever and use the right mechanism to do the over-rides.
Suggested-by Michal Marek <[email protected]>
Cc Geert Uytterhoeven <[email protected]>
Cc <[email protected]>
Signed-off-by Vineet Gupta <[email protected]>
---
 arch/arc/Makefile | 1 +
 1 file changed, 1 insertion(+)

Quoted 12 lines

Quoted 10 lines
arch/arc/Makefile endif · line 48
Quoted 10 lines
arch/arc/Makefile +1 -0
index 86c71b2089d2..c23f3f2b0ff8 100644
@@ -44,6 +44,7 @@ endif
 ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
 # Generic build system uses -O2, we want -O3
 cflags-y  += -O3
+KCFLAGS += -O3
 endif
Uh, this is not what I meant. KCFLAGS is a *user* setting. It's meant to be set in the environment or command line.

Well I don't want to rely on external settings whatsoever to enforce this. If this is not the right way, what do u suggest I do to help fix this.

-Vineet

Vineet Gupta

author

2015-06-24 12:20 UTC #11 lore raw

Hi Michal,

Quoted 62 lines · Vineet Gupta

Quoted 48 lines · Michal Marek
Dne 18.6.2015 v 10:45 Vineet Gupta napsal(a):
Quoted 47 lines
Quoted 47 lines · Michal Marek
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Alternatively, as we already have CONFIG_CC_OPTIMIZE_FOR_SIZE, a(nother) Kconfig option may make sense.
We can also introduce some ARCH_CFLAGS that is appended near the end of the list, and have arc/Makefile add its -O3 there. But I'd like to why the -O3 needs to be there in first place.
This is how historically ARC kernels have been built. We do track performance results LMBench/hackbench... and going from -O3 to -O2 caused a sudden dip in some of the numbers when we measured 3.18 (vs. 3.13)
Quoted 2 lines
Quoted 2 lines
Obviously, the kernel works
with -O2, otherwise the regression would have been identified earlier.
Its a performance thing - so yeah -O2 works, but -O3 works even better :-)
Quoted 2 lines
Quoted 2 lines
So why can't users specify -O3 in KCFLAGS like on any other architecture.
Sweet, I didn't know about this. But I don't see any arch setting this - only tile using it. So yeah - below does the trick !
--------->
From 5e44cd2ed69b1d030b4cb87600d2767b69c35537 Mon Sep 17 00:00:00 2001
From: Vineet Gupta <[email protected]>
Date: Thu, 18 Jun 2015 13:54:01 +0530
Subject: [PATCH] ARC: Override toplevel default -O2 with -O3
ARC kernels have historically been built with -O3, despite top level Makefile defaulting to -O2. This was facilitated by implicitly ordering of arch makefile include AFTER top level assigned -O2.
An upstream fix to top level a1c48bb160f ("Makefile: Fix unrecognized cross-compiler command line options") changed the ordering, making ARC -O3 defunt.
Fix that by NOT relying on any ordering whatsoever and use the right mechanism to do the over-rides.
Suggested-by Michal Marek <[email protected]>
Cc Geert Uytterhoeven <[email protected]>
Cc <[email protected]>
Signed-off-by Vineet Gupta <[email protected]>
---
 arch/arc/Makefile | 1 +
 1 file changed, 1 insertion(+)
Quoted 12 lines
Quoted 10 lines
arch/arc/Makefile endif · line 48
Quoted 10 lines
arch/arc/Makefile +1 -0
index 86c71b2089d2..c23f3f2b0ff8 100644
@@ -44,6 +44,7 @@ endif
 ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
 # Generic build system uses -O2, we want -O3
 cflags-y  += -O3
+KCFLAGS += -O3
 endif
Uh, this is not what I meant. KCFLAGS is a *user* setting. It's meant to be set in the environment or command line.

Quoted 2 lines

Well I don't want to rely on external settings whatsoever to enforce this. If this is not the right way, what do u suggest I do to help fix this.

Can I keep this seeming abuse of KCFLAGS or do u suggest alternate approach I can code up !

Thx,
-Vineet

Michal Marek

2015-07-01 15:19 UTC #12 lore raw

Quoted 11 lines · Vineet Gupta

Quoted 6 lines · Vineet Gupta
Quoted 2 lines · Michal Marek
Uh, this is not what I meant. KCFLAGS is a *user* setting. It's meant to be set in the environment or command line.
Well I don't want to rely on external settings whatsoever to enforce this. If this is not the right way, what do u suggest I do to help fix this.
Can I keep this seeming abuse of KCFLAGS or do u suggest alternate approach I can code up !

Hi Vineet, sorry for the late reply. I had something like the below patch in mind, simply allow arc to specify -O3 in ARCH_CFLAGS (that part I'm leaving up to you).

Vineet Gupta

author

2015-07-02 05:27 UTC #13 lore raw

ARC build -O3 (was Re: subtle side effect of commit a1c48bb160f836)

Quoted 6 lines · Michal Marek

Quoted 5 lines · Vineet Gupta
Quoted 4 lines · Vineet Gupta
Quoted 2 lines · Michal Marek
Uh, this is not what I meant. KCFLAGS is a *user* setting. It's meant to be set in the environment or command line.

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
Well I don't want to rely on external settings whatsoever to enforce this. If this is not the right way, what do u suggest I do to help fix this.
Can I keep this seeming abuse of KCFLAGS or do u suggest alternate approach I can code up !
Hi Vineet, sorry for the late reply.

NP !

Quoted 3 lines

I had something like the below
patch in mind, simply allow arc to specify -O3 in ARCH_CFLAGS (that part I'm leaving up to you).

See below !

Quoted 14 lines

From e458fdf4ae37e1adce81b58d96b1075b4f0656e6 Mon Sep 17 00:00:00 2001
From: Michal Marek <[email protected]>
Date: Wed, 1 Jul 2015 17:13:16 +0200
Subject: [PATCH] kbuild: Allow arch Makefiles to override {cpp,ld,c}flags
Since commit a1c48bb1 (Makefile: Fix unrecognized cross-compiler command line options), the arch Makefile is included earlier by the main Makefile, preventing the arc architecture to set its -O3 compiler option. Since there might be more use cases for an arch Makefile to fine-tune the options, add support for ARCH_CPPFLAGS, ARCH_AFLAGS and ARCH_CFLAGS variables that are appended to the respective kbuild variables. The user still has the final say via the KCPPFLAGS, KAFLAGS and KCFLAGS variables.

Quoted 2 lines

Reported-by Vineet Gupta <[email protected]>
Signed-off-by Michal Marek <[email protected]>

Sweet, that works for me with the following patch below.

Some logistics things:
- It would be nice to keep both of these patches together - do u want to do that or want me to pick this one up
- For ARC this fixes a regression starting 3.16 - so I'll need a stable backport which but obviously requires above to go to stable. Do u have any issues with that. Shall we do the stable request after these hit the mainline...

------------->

Michal Marek

2015-07-02 19:50 UTC #14 lore raw

Re: ARC build -O3 (was Re: subtle side effect of commit a1c48bb160f836)

Dne 2.7.2015 v 07:27 Vineet Gupta napsal(a):

Quoted 38 lines · Michal Marek

Quoted 6 lines · Vineet Gupta
Quoted 5 lines · Vineet Gupta
Quoted 4 lines · Michal Marek
Quoted 2 lines
Uh, this is not what I meant. KCFLAGS is a *user* setting. It's meant to be set in the environment or command line.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Well I don't want to rely on external settings whatsoever to enforce this. If this is not the right way, what do u suggest I do to help fix this.
Can I keep this seeming abuse of KCFLAGS or do u suggest alternate approach I can code up !
Hi Vineet, sorry for the late reply.
NP !
Quoted 3 lines
I had something like the below
patch in mind, simply allow arc to specify -O3 in ARCH_CFLAGS (that part I'm leaving up to you).
See below !
Quoted 14 lines
From e458fdf4ae37e1adce81b58d96b1075b4f0656e6 Mon Sep 17 00:00:00 2001
From: Michal Marek <[email protected]>
Date: Wed, 1 Jul 2015 17:13:16 +0200
Subject: [PATCH] kbuild: Allow arch Makefiles to override {cpp,ld,c}flags
Since commit a1c48bb1 (Makefile: Fix unrecognized cross-compiler command line options), the arch Makefile is included earlier by the main Makefile, preventing the arc architecture to set its -O3 compiler option. Since there might be more use cases for an arch Makefile to fine-tune the options, add support for ARCH_CPPFLAGS, ARCH_AFLAGS and ARCH_CFLAGS variables that are appended to the respective kbuild variables. The user still has the final say via the KCPPFLAGS, KAFLAGS and KCFLAGS variables.

Quoted 8 lines

Quoted 2 lines
Reported-by Vineet Gupta <[email protected]>
Signed-off-by Michal Marek <[email protected]>
Sweet, that works for me with the following patch below.
Some logistics things:
- It would be nice to keep both of these patches together - do u want to do that or want me to pick this one up

Feel free to pick up my patch.

Quoted 3 lines

- For ARC this fixes a regression starting 3.16 - so I'll need a stable backport which but obviously requires above to go to stable. Do u have any issues with that. Shall we do the stable request after these hit the mainline...

Or just add

Cc [email protected] # 3.16+

to the patches.

Michal

Vineet Gupta

author

2015-07-03 02:58 UTC #15 lore raw

Re: ARC build -O3 (was Re: subtle side effect of commit a1c48bb160f836)

Quoted 10 lines · Michal Marek

Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Reported-by Vineet Gupta <[email protected]>
Signed-off-by Michal Marek <[email protected]>
Sweet, that works for me with the following patch below.
Some logistics things:
- It would be nice to keep both of these patches together - do u want to do that or want me to pick this one up
Feel free to pick up my patch.

Ok !

Quoted 7 lines

Quoted 3 lines
Quoted 3 lines
- For ARC this fixes a regression starting 3.16 - so I'll need a stable backport which but obviously requires above to go to stable. Do u have any issues with that. Shall we do the stable request after these hit the mainline...
Or just add
Cc [email protected] # 3.16+

Sure, I just wanted to ensure stable backport was OK for top level Makefile.

I just tried to apply it to 3.17.8 and and it doesn't thus will likely get dropped by stable folks without a fixed up version.

I've added a "Depends-on" tag to ARC patch just in case.

-Vineet