This patch cleans up the usage of CFLAGS. This is nice for packagers, who would like to control the base compilation flags from a central place. I''ve put some default CFLAGS (-Wall -O3) in Config.mk, and removed redundant flags from the Makefiles. I''ve also fixed a few places that didn''t properly inherit CFLAGS from Config.mk (but not vmxassist or hvmloader; those ignore global defaults like before). Also, individual makefiles still add their own custom flags (-g, -Werror, -f*, etc) just as before. Please apply to xen-unstable. Signed-off-by: Charles Coffing <ccoffing@novell.com> Thanks, Charles _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 9 Mar 2006, at 19:42, Charles Coffing wrote:> I''ve put some default CFLAGS (-Wall -O3) in Config.mk, and removed > redundant flags from the Makefiles. I''ve also fixed a few places that > didn''t properly inherit CFLAGS from Config.mk (but not vmxassist or > hvmloader; those ignore global defaults like before). Also, individual > makefiles still add their own custom flags (-g, -Werror, -f*, etc) just > as before. > > Please apply to xen-unstable.I''ll take a look at applying some of these piecemeal. After a quick browse I see that the miniterm Makefile is broken (it is intended to be built and installed on the external box, not the Xen box, so HOSTCC is probably right for it but the potentially cross-compiling CC is definitely not), and the changes to vmxassist and hvmloader have no effect and I see no reason to prefer them over what is there already. No comment on the rest as yet... -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On Thu, Mar 9, 2006 at 12:47 PM, in message<7b2382655a2fb46f17db47d57d745413@cl.cam.ac.uk>, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> On 9 Mar 2006, at 19:42, Charles Coffing wrote: > >> I''ve put some default CFLAGS (- Wall - O3) in Config.mk, and removed >> redundant flags from the Makefiles. I''ve also fixed a few places that >> didn''t properly inherit CFLAGS from Config.mk (but not vmxassist or >> hvmloader; those ignore global defaults like before). Also, individual >> makefiles still add their own custom flags (- g, - Werror, - f*, etc) just >> as before. >> >> Please apply to xen- unstable. > > I''ll take a look at applying some of these piecemeal. After a quick > browse I see that the miniterm Makefile is broken (it is intended to be > built and installed on the external box, not the Xen box, so HOSTCC is > probably right for it but the potentially cross- compiling CC is > definitely not), and the changes to vmxassist and hvmloader have no > effect and I see no reason to prefer them over what is there already. > No comment on the rest as yet...Ah, agreed on both counts. Regarding the change in vmxassist and hvmloader: I was being overly cautious, setting CFLAGS to a non-empty string to be sure it wasn''t defaulted to something else, but indeed setting to an empty string as was done before is sufficient. So I have thrown out the changes to both of those Makefiles. nsplitd is to be treated the same as miniterm, correct? So you should both of their respective patches. (When packaging, we of course would build those things with the same flags, and for the same architecture, but that is a patch I can carry separately .) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 9 Mar 2006, at 19:47, Keir Fraser wrote:> I''ll take a look at applying some of these piecemeal. After a quick > browse I see that the miniterm Makefile is broken (it is intended to > be built and installed on the external box, not the Xen box, so HOSTCC > is probably right for it but the potentially cross-compiling CC is > definitely not), and the changes to vmxassist and hvmloader have no > effect and I see no reason to prefer them over what is there already. > No comment on the rest as yet...The rest looked okay to me, except I''m not 100% sure about pulling the optimisation level out to Config.mk. It means if things liek Xen itself want to make a debug build, they''d have to strip out the passed-in ''-O?'' option which is a pain. So I left that part of the patch out for now. And I made -Wall unconditionally added to CFLAGS in Config.mk instead of "?=". I don''t think it can ever hurt? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 9 Mar 2006, at 20:16, Charles Coffing wrote:> Ah, agreed on both counts. > > Regarding the change in vmxassist and hvmloader: I was being overly > cautious, setting CFLAGS to a non-empty string to be sure it wasn''t > defaulted to something else, but indeed setting to an empty string as > was done before is sufficient. So I have thrown out the changes to > both of those Makefiles. > > nsplitd is to be treated the same as miniterm, correct? So you should > both of their respective patches. (When packaging, we of course would > build those things with the same flags, and for the same architecture, > but that is a patch I can carry separately .)I''ve also now pulled the debug option out into Config.mk, and therefore pulled -O3 and -fomit-frame-pointer into that same file. I also fixed up the ioemu build to respect CFLAGS (was being overridden by a file generated by the configure script) -- in general I think the build process for ioemu needs better integration with our build system. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Friday 10 March 2006 15:58, Keir Fraser wrote:> > On 10 Mar 2006, at 14:50, Andi Kleen wrote: > > >> I''ve put some default CFLAGS (-Wall -O3) > > > > Are you sure -O3 is a good idea? In my experience it just bloats > > .text for most projects because of its aggressive inlining. I would > > use -O2. > > That''s a good question. All that patch really did was move the > optimisation default into Config.mk, and the general choice throughout > the Xen tree was -O3. But it isn''t clear that''s best.The main linux kernel switched to -Os by default now. Rationale is that for kernel code it''s best to be as small in icache as possible and the optimizations in -O2 mostly help loops etc which kernel code doesn''t tend to do a whole lot of. Drawback is that it used to trigger some gcc code generation books, but at least now it seems to be ok (i''m not aware of any current issues) On x86-64 I''m also using -fno-reorder-blocks. The main reason is that it also makes the code a bit smaller and more important it''s much easier to read the assembly code during debugging because it matches the C code better. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"Charles Coffing" <ccoffing@novell.com> writes:> This patch cleans up the usage of CFLAGS. This is nice for packagers, > who would like to control the base compilation flags from a central > place. > > I''ve put some default CFLAGS (-Wall -O3)Are you sure -O3 is a good idea? In my experience it just bloats .text for most projects because of its aggressive inlining. I would use -O2. -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Mar 2006, at 14:50, Andi Kleen wrote:>> I''ve put some default CFLAGS (-Wall -O3) > > Are you sure -O3 is a good idea? In my experience it just bloats > .text for most projects because of its aggressive inlining. I would > use -O2.That''s a good question. All that patch really did was move the optimisation default into Config.mk, and the general choice throughout the Xen tree was -O3. But it isn''t clear that''s best. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
-O2 actually tends to be my preference too for the same reason, but I was just rearranging the existing options. I''ve certainly seen cases (prior to Xen, though) where -O3 was slower than -O2, probably due to cache effects.>>> On Fri, Mar 10, 2006 at 7:50 AM, in message<p73slpquzfr.fsf@verdi.suse.de>, Andi Kleen <ak@suse.de> wrote:> "Charles Coffing" <ccoffing@novell.com> writes: > >> This patch cleans up the usage of CFLAGS. This is nice forpackagers,>> who would like to control the base compilation flags from a central >> place. >> >> I''ve put some default CFLAGS (- Wall - O3) > > Are you sure - O3 is a good idea? In my experience it just bloats > .text for most projects because of its aggressive inlining. I would > use - O2. > > - Andi_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Mar 2006, at 08:30, Andi Kleen wrote:> The main linux kernel switched to -Os by default now. Rationale > is that for kernel code it''s best to be as small in icache as possible > and the optimizations in -O2 mostly help loops etc which kernel > code doesn''t tend to do a whole lot of.Well, moving to -O2 at least looks sane. I noticed -O3 can go a bit mad with auto inlining.> On x86-64 I''m also using -fno-reorder-blocks. The main reason is that > it also makes the code a bit smaller and more important it''s much > easier > to read the assembly code during debugging because it matches the C > code > better.I use that flag too, mainly because I stole x86/64 Xen CFLAGS from Linux. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel