Giving profiled object files a different extension (was: RE: Profiling suggestion)

newer
GHC 5.02.3 binaries for OpenBSD...

Simon Marlow

10 May 2002 10 May '02

11:24 a.m.

Re the current and recurring conflicts between profiling and non-profiling code; how hard would it be to name GHC's output files differently when compiling with -prof?

I.e. without, you get the normal foo.hs -> foo.o result, but with -prof you could get e.g. foo.po or foo.p.o instead? (And of course, linking these instead when making the executable)

I can probably hack this in a makefile, but it'd be nice to be able to just ghc --make as well.

We've wondered about this from time to time, but it's not clear to me that it's an all-round good idea. So if anyone else has any opinions please chime in - if the general concensus is to make this change then we'll do it. The proposal, therefore, is to extend the meaning of '-prof' to mean '-prof -osuf p_o -hisuf p_hi' or similar. To summarise the advantages/disadvantages: - win: you could store profiled and normal objects in the same directory. - win: you'd be less likely to mix up profiled and normal objects. - lose: Makefile writing gets harder. Extra suffix rules have to be added to deal with the new suffixes, and 'make depend' has to add dependency rules for the extra suffixes (ghc -M has some support for doing this). If you're using ghc --make this doesn't affect you. Cheers, Simon

Show replies by date

ketil＠ii.uib.no

13 May 13 May

2:57 a.m.

"Simon Marlow" writes:

...

The proposal, therefore, is to extend the meaning of '-prof' to mean '-prof -osuf p_o -hisuf p_hi' or similar.

I wasn't aware of these ('-*suf') options. Are they respected by the linker stage? I.e. will ghc --make when invoked with -osuf and -hisuf entirely ignore .o's and only link the specified suffixes? Going to have to try that... ...wow, great! Nevermind I asked, and thank you!

...

- win: you could store profiled and normal objects in the same directory.

That'd be nice, of course, but any solution that kept me from linking profiling and non-profiling objects would be great. (With my current setup, I have targets for normal, -O and -prof compilation, but I need to 'make clean' before I change targets...and I'd rather not do that for *every* compile, of course)

...

- win: you'd be less likely to mix up profiled and normal objects.

...

- lose: Makefile writing gets harder. Extra suffix rules [...] If you're using ghc --make this doesn't affect you.

I'm using Makefiles, but with ghc --make in them. So, another solution for *my* problem (but perhaps not others') would be for ghc --make to check for profiling/non-profilng objects and recompile them if they don't match the current options. A bit more compilation, a bit less directory clutter. Perhaps harder to implement? (A third option might be to put object files in a separate directory from the source.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Malcolm Wallace

16 May 16 May

9:17 a.m.

"Simon Marlow" writes:

...

...
Re the current and recurring conflicts between profiling and non-profiling code; how hard would it be to name GHC's output files differently when compiling with -prof?

The proposal, therefore, is to extend the meaning of '-prof' to mean '-prof -osuf p_o -hisuf p_hi' or similar.

It might be worth pointing out that nhc98 already does something like this, and we find that it is definitely a big win. We settled on .p.o for heap profiling and .z.o for time profiling (also .T.o for tracing, but that may disappear shortly with the advent of portable Hat).

...

To summarise the advantages/disadvantages: - win: you could store profiled and normal objects in the same directory.

Very handy, because it means you can switch between normal and profiled versions of a project without having to do a complete rebuild every time.

...

- win: you'd be less likely to mix up profiled and normal objects.

Mixing up object files was an absolute pain in the backside, and happened far too frequently, until we adopted separate suffixes.

...

- lose: Makefile writing gets harder. Extra suffix rules have to be added to deal with the new suffixes, and 'make depend' has to add dependency rules for the extra suffixes (ghc -M has some support for doing this). If you're using ghc --make this doesn't affect you.

Worth noting also that `hmake' currently understands that -p (for nhc98) means to look for the .p.o suffix etc. It would be very straightforward to extend the mechanism to do the same or similar for ghc. Regards, Malcolm

Hal Daume III

18 Jun 18 Jun

2:16 p.m.

For what it's worth (I don't know whether defaulting -prof to mean '-prof -osuf p_o -hisuf p_hi' was going to be adopted or not), but I'm against it. I name my o file by $ARCH.o and my hi files by $ARCH.hi and profiled by $ARCH.p.o, etc...I basically do this by aliasing in my .cshrc ghc to ghc -osuf $ARCH.o -hisuf $ARCH.hi; this means I don't have to worry about "make clean"ing every time I build for different architectures (I usually have a sun4 build and a linux i686 build laying around). I then have another alias ghcp for profiling which uses -osuf $ARCH.p.o, etc. As long as this default is overridden by explicit options, I'm fine with it, but please don't hardwire it :). - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Thu, 16 May 2002, Malcolm Wallace wrote:

...

"Simon Marlow" writes:

...
...
Re the current and recurring conflicts between profiling and non-profiling code; how hard would it be to name GHC's output files differently when compiling with -prof?

The proposal, therefore, is to extend the meaning of '-prof' to mean '-prof -osuf p_o -hisuf p_hi' or similar.

It might be worth pointing out that nhc98 already does something like this, and we find that it is definitely a big win. We settled on .p.o for heap profiling and .z.o for time profiling (also .T.o for tracing, but that may disappear shortly with the advent of portable Hat).

...
To summarise the advantages/disadvantages: - win: you could store profiled and normal objects in the same directory.

Very handy, because it means you can switch between normal and profiled versions of a project without having to do a complete rebuild every time.

...
- win: you'd be less likely to mix up profiled and normal objects.

Mixing up object files was an absolute pain in the backside, and happened far too frequently, until we adopted separate suffixes.

...
- lose: Makefile writing gets harder. Extra suffix rules have to be added to deal with the new suffixes, and 'make depend' has to add dependency rules for the extra suffixes (ghc -M has some support for doing this). If you're using ghc --make this doesn't affect you.

Worth noting also that `hmake' currently understands that -p (for nhc98) means to look for the .p.o suffix etc. It would be very straightforward to extend the mechanism to do the same or similar for ghc.

Regards, Malcolm _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ketil＠ii.uib.no

19 Jun 19 Jun

5:54 a.m.

Hal Daume III writes:

...

For what it's worth (I don't know whether defaulting -prof to mean '-prof -osuf p_o -hisuf p_hi' was going to be adopted or not), but I'm against it.

Yep. I don't remember if I was the one raising the issue or just participating, but I'm perfectly satisfied with the -osuf and -hisuf options (which I hadn't discovered at the time). (I still advocate generating a warning/error when GHC is used to link profiling and non-profiling object files, though. But as it never happens anymore, it's not a big deal.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

8371

Age (days ago)

8411

Last active (days ago)

List overview

Download

4 comments

4 participants

participants (4)

Hal Daume III
ketil＠ii.uib.no
Malcolm Wallace
Simon Marlow